Connection between Prism WPF and the Application class

Aug 20, 2009 at 7:05 PM

Our program is using Prism 2.0.  The program defines the "Application" class somewhere else and then calling the Prism bits.  I can't seem to get this to work.  I have narrowed the problem to the following simple steps:

- Take the HelloWorld.Desktop example that is in the QuickStart folder.

- Exclude the App.xaml (and corresponding cs) file.

- Instead put the following Program.cs file.  What is really interesting is that the application works if I use the "dummy" App2 class.  If I use the "Application" class, the program does not display the contents of the shell window.  Can anyone please help explain what is the connection between Prism and the Application class?

using System;
using System.Windows;

namespace HelloWorld.Desktop
{
    public class App2 : Application
    {
    }

    class Program
    {
        [STAThread]
        static void Main(string[] args)
        {
            // Program does not work if I use Application()
            var app = new Application();

            // Program works if I use App2().  App2 derived from Application but does nothing in and of itself.
            //var app = new App2();

            var bs = new Bootstrapper();
            bs.Run();

            app.Run();
        }
    }
}

Aug 21, 2009 at 5:29 PM

Hi

The Application class is the entry point in any WPF/Silverlight application. To create Prism applications, you  create a new instance of your application’s Bootstrapper in the OnStartup method of the application class. This in turns creates the Shell of your application. You can read more about that here:

If you have a console application that is in charge of launching the Prism application, you can run the bootstrapper directly from it (without using the Application class), which will launch the Shell. The following thread deals with a similar situation (launching a Prism app from a console app) and talks about some possible limitations about this:

Please let me know if this helps.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman