Question

So I’ve got this nice little MVVM solution, and things work great. I’ve got a view model for a header bar that adjusts the icon based on the state of the application, etc. I’ve done acceptance tests, the view model works great.

So I want to unit test the behavior of this view model. I create my unit testing project, add a new unit test for the view model, and write a simple smoke test. (i.e. Given mocked dependencies, will the class instantiate).

Bam, no

However, the class works fine when ran normally. Upon further inspection, my error is as follows:

TestInitialize threw exception: System.UriFormatException: Invalid URI: Invalid port specified.

So following the call stack I arrive at the conclusion that my pack URLs used to load resource streams are the ones kicking the errors.

pack://application:,,,/Operations.Shell;component/Media/Images/User_Normal.png

(Note: Operations.Shell is the assembly name, /Media/Images/User_Normal.png is the image path/name, and this pack url works in practice.)

Is the pack url I have for my User_Normal.png, the file exists, the resource is properly packed into the assembly (checked with reflector).

The problem arises from the System.Uri class not being able to interpret the pack url. This is where I’m getting lost. Why would this not work in the confines of testing. I have all the WPF Assemblies referenced in my test project:

• WindowsBase
• PresentationCore
• PresentationFramework
• System.Xaml

What am I missing?

Update

Alright so the original problem was that the UriHandler wasn’t registered for pack urls. (Thanks to Julien Lebosquain) Now that that’s fixed it’s still having issues.

TestInitialize threw exception: System.NotSupportedException: The URI prefix is not recognized.

System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
System.Net.WebRequest.Create(Uri requestUri)
MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
System.IO.Packaging.PackWebRequest.GetRequest(Boolean allowPseudoRequest)
System.IO.Packaging.PackWebRequest.GetResponse()
MS.Internal.WpfWebRequestHelper.GetResponse(WebRequest request)
System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(Uri uri, Stream stream, BitmapCacheOption cacheOption, Guid& clsId, Boolean& isOriginalWritable, Stream& uriStream, UnmanagedMemoryStream& unmanagedMemoryStream, SafeFileHandle& safeFilehandle)
System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy, Boolean insertInDecoderCache)
System.Windows.Media.Imaging.BitmapImage.FinalizeCreation()
System.Windows.Media.Imaging.BitmapImage.EndInit()
System.Windows.Media.Imaging.BitmapImage..ctor(Uri uriSource, RequestCachePolicy uriCachePolicy)
System.Windows.Media.Imaging.BitmapImage..ctor(Uri uriSource)
MyFramework.Resources.b__1(Uri u)
MyFramework.Resources.ResourceType`1.Load(String path)
Operations.Shell.AppShell.ViewModels.HeaderViewModel..ctor(IEventAggregator eventAggregator, ISecurityService securityService)
Tests.Shell.AppShell.TestHeaderViewModel.TestInitialize()

It looks like the pack url’s trying to resolve to something web-based for an assembly pack url? Looks like the handler’s routing the request wrong? Or am I missing something?

Answer 1

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.