Completamente cancellato "App.xaml" e creato il proprio punto di ingresso, quali sono le conseguenze?

Question

Ho appena rimosso "App.xaml" interamente dalla mia soluzione e ho creato la mia classe di ingresso xamlless dove sto implementando il metodo statico tradizionale Main().

sto instancing un nuovo Application di classe e la sua creazione prima di chiamare il suo metodo Run(), dandogli un StartupUri, così aggiungendo ad esso una nuova risorsa-dizionario così i miei stili vengono applicate automaticamente. Tutto funziona come previsto, viene visualizzata la finestra principale, le risorse vengono caricate e i modelli vengono applicati correttamente su tutti i controlli e le finestre.

Ma ho bisogno di sapere se ci sono delle conseguenze negative facendo così? Che cosa mi ha offerto la classe App, quindi dovrei tenerla invece di sostituirla con il mio punto di ingresso compatto e senza xamess, che mi ha dato lo stesso risultato esatto?

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

Guardando nella classe App nel decompilatore rivela questo metodo generato automaticamente nella classe App:

/// <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(); 
} 

Quindi, direi, non c'è alcuna differenza in termini di ciò che accade in fase di esecuzione. Ha influito sulla nostra esperienza di sviluppo, però.

Ho anche utilizzato l'approccio manuale e l'unico lato negativo che ho visto è che ReSharper non raccoglie risorse a livello di applicazione, quindi non sono disponibili nel completamento del codice XAML e ci sono un gran numero di avvisi per questo. Per mitigarlo ho dovuto aggiungere un falso file App.xaml al progetto. ReSharper cerca in particolare un file .xaml con l'azione di build ApplicationDefinition, quindi è possibile mantenere il punto di ingresso diverso per soddisfare sia ReSharper sia la necessità di utilizzare un punto di ingresso personalizzato.

Un'altra cosa, si può vedere qui che è diverso da altri file .xaml è che il metodo InitializeComponent viene chiamato separatamente anziché essere chiamato nel costruttore overriden. Pertanto, se decidi di utilizzare la classe di applicazione con backup XAML nel tuo punto di ingresso personalizzato, dovrai anche chiamare questo metodo separatamente oppure aggiungere una sovrascrittura del costruttore che esegue questa operazione perché non è stata creata per impostazione predefinita.