Perché gli assembly firmati si caricano lentamente?

Question

Questa settimana ho riscontrato uno strano problema che non posso spiegare: ho cambiato la mia applicazione per utilizzare la versione firmata di alcuni assembly 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, il caricamento richiedeva 30 secondi. L'avvio dell'applicazione è passato da 5 secondi a oltre 90 secondi. Cosa diavolo sta succedendo qui ?!

Alcune altre informazioni:

• Questa è un'app WinForms in esecuzione su .NET 3.5 SP1.
• Il computer non aveva una connessione Internet (apposta, per sicurezza).

Answer 1

Dai 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

Potrebbero aiutare. È possibile che la configurazione del sistema in uso significhi che .NET Framework sta facendo molto lavoro extra per verificare l'assemblaggio. In questo caso, puoi configurarlo in modo che non sia così schizzinoso.

Answer 2

Il post di Jason Evans contiene la risposta, ma sotto forma di un link. Ho pensato che sarebbe bello pubblicare qui la soluzione attuale:

Crea un file Appname.exe.config nella stessa cartella dell'eseguibile (dove Appname è il nome del tuo eseguibile; per lo sviluppo, questo sarebbe nella cartella di output del debug). Questo mostra un file xml che presuppone che non ci siano altre voci nel file di configurazione principale; se hai già il file, suppongo che aggiungeresti le nuove sezioni / testo come necessario:

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

Answer 3

Nel caso in cui qualcun altro si imbattesse in questo post, ho rintracciato il problema un po 'di più, perché stavo solo cercando di capirlo e ho trovato questa pagina.

Sembra che il CRL sia verificato ogni volta che si esegue il processo se il CRL esistente che si trova sul computer è scaduto e non è ancora aggiornato con uno nuovo. Puoi verificarlo premendo CRL su http://crl.microsoft.com/ pki / crl / products / CodeSignPCA.crl e controlla la data di scadenza. Ora configura un proxy all'interno di IE che non funziona. Impostare la data della macchina oltre la data di scadenza e ripetere il test dell'applicazione.

Se la scheda di rete è disabilitata, il CRL non è selezionato.

Se la scheda di rete non ha gateway, il CRL non è verificato.

Se si dispone di un proxy abilitato e di un gateway, viene controllato il CRL e se si verifica un problema con il proxy, si verificherà questo timeout.

Se ti connetti a Internet con successo, allora il CRL si aggiorna e per il momento andrà bene.

La mia applicazione utilizzava alcuni componenti Xceed precedenti in .NET 2.0 e ha funzionato per sempre, quindi ci è voluto del tempo per capire cosa stesse succedendo.

Answer 4

Il caricamento di assembly firmati sarà sicuramente più lento rispetto alle controparti non firmate perché la firma deve essere verificata, ma questo dovrebbe essere completamente trascurabile.

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

Answer 5

Immagino che tu abbia impostato le impostazioni di sicurezza in modo tale da verificare i certificati degli assembly. Quindi probabilmente prova ad accedere al Web per verificare alcuni certificati e quindi attende un timeout (30 secondi è un numero di timeout MOLTO tipico).

Puoi verificarlo se guardi cosa succede in quei 30 secondi. Per quanto possa essere vero, in quei 90 secondi dovrebbero esserci pochi usi della CPU e piccoli accessi all'HDD. Se hai un elevato utilizzo della CPU o legato dal tuo HDD, allora è qualcos'altro.

A proposito: un'altra opzione sarebbe se il tuo HDD è completamente pieno e gli assemblaggi sono ESTREMAMENTE frammentati (ma 90 secondi sarebbero più di quanto io abbia mai sentito parlare in quel caso).

Answer 6

Prova ad avviare l'applicazione da Visual Studio con " Passa sopra " ;. Questo avvierà il codice passando sopra 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 è posizionare il punto di interruzione sparso attraverso il codice di caricamento e vedere qual è il collo di bottiglia. Se l'applicazione impiega 90 secondi prima prima il tuo , probabilmente qualcosa con XCeed o il caricamento degli assembly firmati.

A proposito, sono consapevole che ci sono modi migliori per profilare la tua applicazione, ma questo modo rapido e sporco funziona abbastanza bene ed efficace per eseguire il debug di tali problemi

Answer 7

Forse le assemblee firmate non sono NGEN, mentre quelle non firmate lo sono.