¿Por qué los ensamblados firmados tardan en cargarse?

Question

Me encontré con un problema extraño esta semana que no puedo explicar: cambié mi aplicación para usar la versión firmada de algunos ensamblajes de terceros (Xceed Grid y algunos de sus otros componentes) y la hora de inicio de la aplicación entró en el inodoro. Cada vez que la aplicación cargaba un ensamblaje firmado, tardaba 30 segundos en cargarse. El inicio de la aplicación pasó de 5 segundos a más de 90 segundos. ¿Qué diablos está pasando aquí?

Algunos otra información:

• Esta es una aplicación que corre bajo Windows Forms .NET 3.5 SP1.
• La computadora no tenía conexión a Internet (a propósito, por razones de seguridad).

Answer 1

Tener un vistazo a estos enlaces:

• 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

Podrían ayudar. Podría ser que la configuración en su sistema significa que .NET Framework está haciendo un trabajo extra para verificar el ensamblaje. Si este es el caso, puede configurarlo para que no sea tan quisquilloso.

Answer 2

Cargando firmado asambleas sin duda será más lenta que sus homólogos no firmado porque la firma necesita ser verificada, pero esto debe ser completamente insignificante.

Pasando de 5 segundos a 90 segundos ?? Creo que debe ponerse en contacto con el autor del ensamblaje y preguntarles si cambiaron solo la firma :-)

Answer 3

Quizás los ensamblajes firmados no sean NGEN, mientras que los ensamblados no firmados sí.

Answer 4

Supongo que tiene la configuración de seguridad configurada de manera que los certificados de ensamblaje se verifiquen. Por lo tanto, es probable que intente acceder a la web para verificar algún certificado y luego espera un tiempo de espera (30 segundos es un número MUY típico de tiempo de espera).

Puede verificar esto si observa lo que sucede en esos 30 segundos. Para mi suposición de que es cierto, debería haber poco uso de CPU y pocos accesos a HDD en esos 90 segundos. Si tiene un uso elevado de CPU o está vinculado a su disco duro, entonces es otra cosa.

BTW: Otra opción sería si su disco duro está completamente lleno y los ensamblajes están EXTREMADAMENTE fragmentados (pero 90 segundos sería más de lo que he escuchado en ese caso).

Answer 5

Intenta iniciar tu aplicación desde Visual Studio con "Step over". Esto iniciará el código pasando por encima de cada aplicación, para que pueda verificar lo que demora tanto. Una vez tuve esto, y resultó que mi servidor SQL estaba realmente en mal estado.

Otra forma de averiguar por qué tarda tanto es colocar el punto de interrupción disperso a través del código de carga y ver cuál es el cuello de botella. Si la aplicación tarda 90 segundos en antes desu primero le gusta, probablemente algo con XCeed, o cargando los ensamblajes firmados.

Por cierto, soy consciente de que hay mejores maneras de perfil de su aplicación, pero esto rápido 'n manera sucia funciona bastante agradable y eficaz para depurar este tipo de problemas

Answer 6

Jason Evans mensaje contiene la respuesta, pero en la forma de un enlace. Pensé que sería bueno publicar la solución real aquí:

Cree un archivo Appname.exe.config en la misma carpeta que el ejecutable (donde Appname es el nombre de su ejecutable; para el desarrollo, esto sería en el carpeta de salida de depuración). Esto muestra un archivo xml que supone que no tiene otras entradas en el archivo de configuración principal; si tiene el archivo ya, supongo que acaba de agregar el nuevo secciones/texto como sea necesario:

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

Answer 7

Sólo en caso cualquier otra persona viene a través de este post, he rastreado el problema un poco más, porque estaba solo tratando de descubrirlo y encontrar esta página.

Parece que la CRL se comprueba cada vez que ejecuta su proceso si se ha agotado el tiempo de la CRL existente en su equipo y aún no se ha actualizado con una nueva. Puede probar esto al presionar la CRL al http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl y verificar la fecha de caducidad. Ahora configura un Proxy dentro de IE que no funciona. Establezca la fecha de su máquina después de la fecha de caducidad y vuelva a probar su aplicación.

Si su NIC está desactivada, la CRL no está marcada.

Si su NIC no tiene puerta de enlace, la CRL no está marcada.

Si tiene un Proxy habilitado y una puerta de enlace, entonces la CRL está marcada y si hay un problema con el Proxy, experimentará este tiempo de espera.

Si se conecta a Internet con éxito, entonces la CRL se actualiza y estará bien por el momento.

Mi aplicación estaba usando algunos componentes Xceed más antiguos en .NET 2.0 y ha estado funcionando para siempre, así que me llevó un tiempo averiguar qué estaba pasando.