Determine si se utilizan conjuntos GAC'ed y NGen'ed

¿Cómo puedo determinar si las imágenes nativas se están utilizando sin que el cargador verifique la firma del ensamblaje en tiempo de ejecución o incluso utilizando el ensamblaje GAC?Determine si se utilizan conjuntos GAC'ed y NGen'ed

Tengo un sistema complejo que estamos experimentando con NGen pero actualmente estamos ejecutando el archivo exe desde la carpeta donde se encuentran todas las DLL debido a una gran cantidad de dependencias vinculantes tardías, mirando Process Explorer, parece que Se están utilizando imágenes nativas, pero ¿cómo puedo estar seguro de obtener el máximo beneficio y eliminar el paso de Verificación de cargador?

Cheers, Graeme.

Actualización: estoy recibiendo una gran cantidad de este tipo de cosas de la Asamblea Encuadernación Visor de registro:

LOG: [Level 1]Start validating IL dependency MyCompany.Entities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd. 
LOG: Dependency evaluation succeeded.

y al final

LOG: Validation of dependencies succeeded. 
LOG: Start loading all the dependencies into load context. 
LOG: Loading of dependencies succeeded. 
LOG: Bind to native image succeeded. 
Native image has correct version information. 
Attempting to use native image C:\Windows\assembly\NativeImages_v2.0.50727_32\MyCompany.Mylibrary#\4710bb8309419d707681bd360088181f\MyCompany.MyLibrary.MyClass.ni.dll. 
ZAP: Native image has been relocated. 
Native image successfully used.

por lo que es el uso de las imágenes nativas pero todavía los verifico, es decir, no estoy usando la versión GAC, aunque ahí es donde creé la imagen nativa, Como que sí:

ngen install "MyCompany.Entites, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd, processorArchitecture=MSIL"

Nota: En este artículo parece dar a entender que si las asambleas no se cargan desde el GAC entonces el proceso de verificación compensará las ventajas NGEN? CLR Inside Out - Improving Application Startup Performance (MSDN)

actualización - Como nobugz ha señalado en un comentario más abajo, el paso de verificación mencionado anteriormente no se realiza desde 3.5 SP1, consulte: MSDN Docs on NGen

Fuente

2010-02-17 Dog Ears

Puede verlo fácilmente desde la herramienta Fuslogvw.exe. Comience desde el símbolo del sistema de Visual Studio. Configúrelo con Categorías de registro = Imágenes nativas, Configuración + Registrar todo se une al disco. Ejecute su programa. Volver a fuslogvw, Actualizar. Le mostrará una lista de todos los ensamblajes que se cargaron.

Haga doble clic en una entrada para ver cómo se cargó el conjunto. Si se trataba de la GAC, verá:

REGISTRO: ensamblaje IL cargado de C: \ Windows \ assembly \ GAC_MSIL \ blahblah

Si se utilizan las imágenes Ngen-cados, se Veremos:

REGISTRO: Enlace a la imagen nativa exitosa.

Fuente

2010-02-17 17:38:19

+1, esto parece prometedor, pero creo que está demostrando que mis imágenes nativas no están siendo utilizadas por el GAC, por lo que aún están siendo validadas por el cargando, efectivamente compensando la ventaja de ngen, vea mis ediciones en original Q. –

@dog - Me parece claro, el ensamblaje no se carga del GAC, pero usa la imagen de Ngen-ed. Esto es normal. No estoy seguro de qué otro problema puede haber, la validación de nombre fuerte se salta con plena confianza si eso es lo que le preocupa. –

He agregado una nota a pie de página, es la verificación del cargador mencionada en ese artículo que estoy tratando de eliminar. –

Se puede ver si el conjunto vino del GAC con bastante facilidad :

Assembly assembly = Assembly.GetExecutingAssembly(); 

if (assembly.GlobalAssemblyCache) 
{ 
    Console.WriteLine("I'm in the GAC!"); 
}

EDIT: encontrado una manera ...

Para ver si está NGEN'd, debe leer el ensamblaje directamente y ver si el campo Encabezado de precompilación tiene datos como this page. Estoy un poco oxidado al llegar a ese valor, pero eso debería hacerlo. No veo una manera de averiguarlo a través de los métodos de reflexión.

Fuente

2010-02-17 16:35:25

Puedo determinar si son NGen al mirar el panel de vista de la DLL en Process Explorer, colocando el cursor sobre el nombre que da la ruta completa como ... c: \ Windows \ Assembly \ NativeImages_v2.0.5072_32 \ MyDll.ni .dll –

Agregué algo de una pista a mi respuesta. –

Motivo del downvote, downvoter? –

Puede usar el VMMAP. Allí, todos los .dll (ensamblado) tienen detalles de ubicación

En detalles si su ensamblaje se carga desde "C: \ Windows \ assembly \ NativeImages (versión) ..." para que su aplicación esté usando la imagen original.

Fuente

2016-10-17 13:16:25

Determine si se utilizan conjuntos GAC'ed y NGen'ed

Respuesta

Cuestiones relacionadas