Modi per accelerare l’avvio di un’applicazione ClickOnce

Ho un’applicazione Visual Studio 2005 / C # ClickOnce che ottiene tutti i suoi dati da un servizio Web . Ho messo a punto l’applicazione in modo che risulti piuttosto scattante per gli utenti, anche se deve andare a recuperare i dati dal servizio Web per quasi tutto.

Tuttavia, l’avvio è ancora piuttosto lento. Sembra che ci vuole un po ‘per generare la prima chiamata al servizio web. Dopo, va bene.

Cosa posso fare per accelerare l’avvio di questo tipo di un’applicazione? Devo generare un assembly di serializzazione?

Dedica del tempo ad analizzare gli assembly caricati dalla tua applicazione. Ciò avrà il massimo effetto sul tempo di caricamento della tua applicazione. Se si dispone di tipi che vengono utilizzati solo occasionalmente, spostarli in un altro assieme. ClickOnce può ottimizzare il download degli assembly su richiesta, quindi ridurre il numero richiesto di assiemi al momento del caricamento lo renderà più veloce.

È anche ansible avere una sorta di launcher “stub” con dipendenze di assembly minimi nulli che carica gli altri assembly in modo dinamico (Assembly.Load) e richiama l’elaborazione reale dopo che sono stati caricati.

È ansible utilizzare i gruppi di file ClickOnce per dividere l’applicazione in parti gestibili e quindi utilizzare l’API ClickOnce per scaricare gruppi quando necessario. L’articolo ClickOnce File Groups spiega come farlo.

Assicurati di ottenere .NET 3.5 SP1 in quanto vi sono miglioramenti significativi delle prestazioni nell’area di avvio. In particolare con le applicazioni WPF.

E per quanto riguarda la chiamata al servizio web, puoi accelerarla se ti assicuri di generare un assembly di serializzazione durante la compilazione. Da quello che posso ricordare, Visual Studio non è molto intelligente nel sapere quando generare automaticamente questo file ma puoi farlo con SGEN.EXE.

Crea un assembly separato come MyApp.XmlSerializer.dll che contiene tutto il codice di serializzazione per la chiamata al servizio web. In caso contrario, l’app eseguirà un probe non riuscito per l’assembly, quindi genererà dynamicmente il codice e lo compilerà in memoria, motivo per cui la prima chiamata al servizio web è lenta.