Replacing the WPF entry point

Some examples depict changing App.xaml's Build Action from ApplicationDefinition to Page and writing your own Main() that instantiates the App class and calls its Run() method, but this can produce some unwanted consequences in the resolution of application-wide resources in App.xaml.

Instead, I suggest making your own Main() in its own class and setting the Startup Object to that class in the project properties:

public class EntryPoint {
    [STAThread]
    public static void Main(string[] args) {
        if (args != null && args.Length > 0) {
            // ...
        } else {
            var app = new App();
            app.InitializeComponent();
            app.Run();
        }
    }
}

I do this to take advantage of some AppDomain events that must be subscribed to before anything else happens (such as AssemblyResolve). The unwanted consequences of setting App.xaml to Page that I experienced included my UserControl Views (M-V-VM) not resolving resources held in App.xaml during design-time.

Typically I edit App.xaml to add this support:

<Application x:Class="SomeNamespace.App"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         Startup="Application_Startup">

The relevant part being I changed from StartupUri to Startup with an event handler in App.xaml.cs. Here is an example:

/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
    private void Application_Startup(object sender, StartupEventArgs e)
    {
        int verbose = 0;
        var optionSet = new OptionSet
        {
            { "v|verbose", "verbose output, repeat for more verbosity.",   
                    arg => verbose++ }
        };

        var extra = optionSet.Parse(e.Args);
        var mainWindow = new MainWindow(verbose);
        mainWindow.Show();
    }
}

Replacing the WPF entry point

Related

Recent Posts