Bad Uri Format

Topics: Bootstrappers & IoC, Conventions, Getting Started
Feb 24, 2012 at 9:37 AM

Hi Guys,

I've just started using Caliburn Micro on a new WP7 app I'm writing, but I'm having some trouble with the UriBuilder.

All my Views live in a folder called View, and all the View Models in a folder called ViewModels and end in ViewModel.

The ViewModels are all registered as _container.PerRequest<AboutViewModel>(); in the bootstrapper.

But when I try navigating using _navigationService.UriFor<AboutViewModel>().Navigate(); I get an argument exception saying the Uri is invalid.  So I had a look at the Uri and it's coming out as "\BatfishSolutions\\Views\AboutView.xaml".

How have I managed that then?  I was expecting "\Views\AboutView.xaml"

Many thanks,


Feb 24, 2012 at 12:51 PM

That's a good question. Can you create a simple sample that reproduces the problem and create a ticket with it attached. Then I can have a look at it and either get a bug fix in the next release and/or recommend a workaround. Thanks.

Feb 27, 2012 at 6:31 AM

I had the same issue, couldn't get around to fixing it. So in the end i created a new project and literally copy pasted all my code to new made classes in the new project and it worked. It's weird Since i didn't change any code, but somehow it worked in the new project.

Feb 27, 2012 at 2:45 PM

did you change were the MainPage.xaml resides as well?  Did you change in the WMManifest.xml the location to where the MainPage.xaml or you what ever you call your starting page?

Oct 13, 2013 at 9:30 AM
I encountered the same problem in one of my apps. Having a look at the internals of Caliburn.Micro, I found that the reason for that effect is rooted in how ViewLocator.DeterminePackUriFromType determines the name of your app package. This code
var assemblyName = viewType.GetTypeInfo().Assembly.GetAssemblyName();
var uri = viewType.FullName.Replace(assemblyName, string.Empty).Replace(".", "/") + ".xaml";
assumes that the root namespace of your app is the assembly name. However, this needs not to be the case, because you can change the assembly name not to match the default namespace in your project settings. In my case, I was able to fix the problem by making sure that "Assembly Name" and "Default Namespace" are the same in the "Application" tab of the project settings.