Entirely deleted "App.xaml" and created own entry point, What are the consequences?

Question

I just removed the "App.xaml" entirely from my solution and created my own xamlless entry class where I'm implementing the traditional static Main() method.

I'm instancing a new Application class and setting it up before calling its Run() method, giving it a StartupUri, As well adding to it a new resource-dictionary so my styles are applied automatically. Everything works as intended, the main window shows up, the resources are loaded and the templates are properly applied on all controls and windows.

But I need to know if there are any bad consequences by doing that? What did that App class offer me so I should keep it instead of replacing it by my own compact and xamlless entry point that gave me the same exact result?

public static class Entry
{
    private static readonly Application _application = new Application();
    [STAThread]
    public static void Main()
    {
        _application.StartupUri = new Uri( "/Eurocentric;component/Interface/MainWindow.xaml" , UriKind.Relative );
        var style = new ResourceDictionary
                    {
                    Source = new Uri( "/Eurocentric;component/Interface/Styles/VictorianStyle.xaml", UriKind.Relative )
                    };
        _application.Resources.MergedDictionaries.Add( style );
        TemplatedWindow.Defaults();
        _application.Run();
    }
}

Answer 1

Looking into the App class in the decompiler reveals this autogenerated method in the App class:

/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public static void Main() {
    RootNamespace.App app = new RootNamespace.App();
    app.InitializeComponent();
    app.Run();
}

So, I'd say, there's no difference in terms of what happens at runtime. It affected our development experience, though.

I've also used the manual approach myself and the one downside I saw is that ReSharper does not pick up application-wide resources, so they're not available in the XAML code completion and there're great number of warnings because of it. To mitigate it I've had to add a fake App.xaml file to the project. ReSharper specifically searches for a .xaml file with the ApplicationDefinition build action, so you can keep the entry point different to satisfy both ReSharper and the need to use a custom entry point.

One other thing, you can see here that's unlike other .xaml files is that the InitializeComponent method is called separately instead of being called in the overriden constructor. So if you'll ever decide to use the XAML-backed Application class in your custom entry point, you'll either need to call this method separately too, or add a constructor override that does this because it's not created by default.