Perché gli assembly firmati sono lenti a caricarsi?

Question

Questa settimana ho riscontrato uno strano problema che non riesco a spiegare: ho spostato la mia applicazione per utilizzare la versione firmata di alcuni gruppi di terze parti (Xceed Grid e alcuni dei loro altri componenti) e l'ora di inizio dell'applicazione è andata in bagno. Ogni volta che l'applicazione caricava un assembly firmato, ci sono voluti 30 secondi per caricarsi. L'avvio dell'applicazione è passato da 5 secondi a oltre 90 secondi. Che diamine sta succedendo qui?!

alcune altre informazioni:

• Si tratta di un'applicazione WinForms in esecuzione sotto .NET 3.5 SP1.
• Il computer non ha avuto connessione a Internet (di proposito, per motivi di sicurezza).

Answer 1

Date un'occhiata a questi link:

• http://blogs.technet.com/markrussinovich/archive/2009/05/26/3244913.aspx
• http://blogs.msdn.com/tess/archive/2008/05/13/asp-net-hang-authenticode-signed-assemblies.aspx

Essi potrebbero aiutare. Potrebbe essere che la configurazione del tuo sistema significhi che il framework .NET sta facendo molto lavoro extra per verificare l'assembly. Se questo è il caso, allora puoi configurarlo per non essere così schizzinoso.

Answer 2

Carica firmata assiemi sarà sicuramente più lento rispetto omologhi non firmato perché firma deve essere verificata, ma questo dovrebbe essere completamente trascurabile.

Passando da 5 secondi a 90 secondi ?? Penso che sia necessario contattare l'autore dell'assemblea e chiedere loro se hanno cambiato solo la firma :-)

Answer 3

Forse gli assembly firmati non sono NGEN, mentre quelli non firmati sono.

Answer 4

Direi che le impostazioni di sicurezza sono impostate in modo tale da verificare i certificati degli assiemi. Quindi probabilmente cerca di accedere al web per verificare alcuni certificati e poi aspetta un timeout (30 secondi è un numero di timeout MOLTO tipico).

È possibile verificare questo se si guarda a ciò che accade in quei 30 secondi. Perché la mia ipotesi sia vera, ci dovrebbero essere pochi utilizzi della CPU e pochi accessi HDD in quei 90 secondi. Se hai un elevato utilizzo della CPU o vincolato dal tuo HDD, allora è qualcos'altro.

BTW: Un'altra opzione potrebbe essere se l'HDD è completamente pieno e gli assiemi sono ESTREMAMENTE frammentati (ma 90 secondi sarebbero più di quanto abbia mai sentito parlare in quel caso).

Answer 5

Prova ad avviare l'applicazione da Visual Studio con "Passaggio". Questo avvierà il codice passando su ogni app, in modo da poter controllare ciò che richiede così tanto tempo. Una volta ho avuto questo, e si è scoperto che il mio server SQL era davvero incasinato.

Un altro modo per scoprire perché ci vuole così tanto tempo è quello di posizionare il punto di interruzione sparsi attraverso il codice di caricamento e vedere qual è il collo di bottiglia. Se l'applicazione richiede 90 secondi prima del è il tuo come prima, probabilmente qualcosa con XCeed, o il caricamento degli assiemi firmati.

Btw, IM consapevoli ci sono modi migliori nel proprio profilo dell'applicazione, ma questa rapida 'n modo sporco funziona abbastanza bello ed efficiente per eseguire il debug tali problemi

Answer 6

Jason Evans' messaggio contiene la risposta, ma nella forma di un link. Ho pensato che sarebbe stato utile postare qui la soluzione:

Creare un file Appname.exe.config nella stessa cartella dell'eseguibile (dove Appname è il nome del file eseguibile; per lo sviluppo, questo sarebbe nel debug cartella di output). Questo mostra un file xml che presume che non ci siano altre voci nel file di configurazione principale; se avete già il file, presumo si sarebbe solo aggiungere il nuovo sezioni/testo come necessario:

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <runtime> 
     <generatePublisherEvidence enabled="false" /> 
    </runtime> 
</configuration> 

Answer 7

Solo in caso chiunque altro si imbatte in questo post, ho rintracciato il problema un po 'più, perché ero Sto solo cercando di capirlo e ho trovato questa pagina.

Sembra che il CRL sia controllato ogni volta che si esegue il processo se il CRL esistente sulla macchina è scaduto, e non ancora aggiornato con uno nuovo. Puoi testare questo colpendo il CRL allo http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl e controllare la data di scadenza. Ora configura un proxy in IE che non funziona. Impostare la data della macchina oltre la data di scadenza e ripetere il test dell'applicazione.

Se la scheda NIC è disabilitata, il CRL non è selezionato.

Se la scheda di rete non dispone di gateway, il CRL non viene controllato.

Se si dispone di un Proxy abilitato e di un gateway, allora il CRL viene controllato e se c'è un problema con il Proxy, si verificherà questo timeout.

Se ci si connette a Internet con successo, l'aggiornamento del CRL andrà bene per il momento.

La mia applicazione utilizzava vecchi componenti Xceed in .NET 2.0 e ha funzionato per sempre, quindi ci è voluto un po 'di tempo per capire cosa stava succedendo.