+1  A: 

I got bitten by this problem once too...

Referencing the assemblies isn't enough. WPF needs to call System.UriParser.Register() with its own URI parser so that System.Uri can interpret pack URLs.

Reflecting tells us that this is done by the static constructor of System.IO.Packaging.PackUriHelper. Call any method of this class in your test, like PackUriHelper.Create() to ensure the URI parser is well registered. Kind of ugly, but should work.

Julien Lebosquain
@Julien Lebosquain - You were right (+1), but there's still problems. Please see the updated section in the original post for further details. Did you have this problem too?
Aren
Solved it. There was more to the WPF Framework that needed initialization to add a url-prefix handler to the WebRequest/WebResponse. I ended up instantiating a `FrameworkElement` object, which seemed to load enough of the framework through static constructors.
Aren
Creating a FrameworkElement will start the same process as creating your application class will, but it will probably be faster. Good to know!
Rune Grimstad
@Rune Grimstad - I gave you +1, the concept is similar to the solution.
Aren
@Aren - hehe. Cool! I wasn't aware that you could ge tthe same effect by creating a FrameworkElement only - I thought you had to create the entire application. So I learned something new today. :-)
Rune Grimstad
+1  A: 

I think you can fix this by creating an instance of your main application class before running any tests. This will wire up the handlers that Julien mentions in the other answer.

Rune Grimstad
I'd rather not spin up my application to test components.
Aren