The Fallacies using Prism for WPF the first Time

Yesterday I started developing a new WPF application using Prism. That’s when I hit a problem with navigation and RegionManager that was very difficult to debug.

The Problem:

Navigating a Region to another control just did not work. The NavigatonResults Result property was false, but no exception was thrown.

RegionManager.RequestNavigate("Content", "Overview", (navigationResult) => Debug.WriteLine(navigationResult.Result));

Then I investigated the RegionManager and checked if it had any registered Regions. And sure enough, it did not.
The weird thing though was that adding a view using RegisterViewWithRegion worked.

RegionManager.RegisterViewWithRegion("Navigation", typeof(NavigationSimple));

The Solution:

I did not override the Bootstrappers CreateShell InitializeShell and methods, because I thought they had a standard implementation using MainWindow, since the MainWindow was shown.
After I have overwritten these methods with my own implementation, suddenly 2 MainWindows were displayed!

protected override DependencyObject CreateShell()
    return new MainWindow();

protected override void InitializeShell()
    Application.Current.MainWindow = (MainWindow)Shell;

That’s when I realized that WPFs Application class, instantiated in App.xaml has a StartupUri property, which is set by default to MainWindow.xaml. This creates and shows the MainWindow. This is a good standard for “normal” WPF developing, but when using Prism it can be very deceiving and lure you into thinking that everything is set up correctly, when in reality it is not.

<Application x:Class="Application.App"

After removing that property everything worked as expected, and my RegionManager had all Regions registered.