¿Cómo puedo determinar las dependencias de una aplicación .NET?

StackOverflow https://stackoverflow.com/questions/227886

Pregunta

¿Cómo puedo determinar las dependencias de una aplicación .NET? ¿El Dependency Walker funciona con aplicaciones administradas? He descargado la última versión y he intentado crear un perfil de la aplicación, pero se cierra sin mucha explicación. Si no funciona con .NET, ¿hay alguna otra herramienta que me ayude a depurar un problema de carga de DLL en tiempo de ejecución?

¿Fue útil?

Solución

Dependency walker funciona en binarios normales de win32. Todos los archivos .NET y exe tienen una pequeña parte de encabezado de código auxiliar que los hace ver como binarios normales, pero todo lo que básicamente dice es que carga el CLR " - así que eso es todo lo que el caminante de dependencias le dirá.

Para ver en qué se basa realmente su aplicación .NET, puede usar el excelente . Reflector NETO de Red Gate. (EDITAR: tenga en cuenta que .NET Reflector ahora es un producto pagado. ILSpy es gratuito y de código abierto y muy similar.)

Cargue su DLL en él, haga clic con el botón derecho y seleccione 'Analizar'; luego verá un " Depende de " elemento que le mostrará todas las demás DLL (y los métodos dentro de esas DLL) que necesita.

Sin embargo, a veces puede complicarse, ya que su aplicación depende de X dll, y X dll está presente, pero por cualquier motivo no se puede cargar o ubicar en tiempo de ejecución.

Para solucionar este tipo de problemas, Microsoft tiene un Asamblea Visor de registro vinculante que le puede mostrar lo que está pasando en tiempo de ejecución

Otros consejos

Encuentro la pequeña utilidad AsmSpy una herramienta invaluable para resolver problemas con la carga de ensamblajes. Enumera todas las referencias de ensamblaje de ensamblados administrados, incluidas las versiones de ensamblaje.

Ejecútelo en un indicador de comando en el directorio de .dll con los siguientes argumentos: 

asmspy . all

captura de pantalla de salida asmspy

Instálalo rápidamente con Chocolatey: 

choco install asmspy

Abra el archivo de ensamblaje en ILDASM y busque @ the .assembly extern en MANIFEST

Para explorar las dependencias del código .NET, puede usar las capacidades de la herramienta NDepend. La herramienta propone:

Por ejemplo, esta consulta puede tener el siguiente aspecto: 

from m in Methods 
let depth = m.DepthOfIsUsing("NHibernate.NHibernateUtil.Entity(Type)") 
where depth  >= 0 && m.IsUsing("System.IDisposable")
orderby depth
select new { m, depth }

Y su resultado se ve así: (observe la métrica del código profundidad , 1 es para llamadores directos, 2 para llamadores de llamantes directos ...) (observe también el botón Exportar a gráfico para exportar el consultar el resultado en un Call Graph )

NDepend dependencias navegando a través de la consulta de C # LINQ

El gráfico de dependencia se ve así:

NDepend Gráfico de dependencia

La matriz de dependencia se ve así:

NDepend Matriz de dependencia

La matriz de dependencias es de-facto menos intuitiva que la gráfica, pero es más adecuada para navegar por secciones complejas de código como:

NDepend Matrix vs Graph

Descargo de responsabilidad: trabajo para NDepend

No es necesario descargar e instalar aplicaciones o herramientas shareware. Puede hacerlo programáticamente desde .NET utilizando Assembly.GetReferencedAssemblies () 

Assembly.LoadFile(@"app").GetReferencedAssemblies()

Si está utilizando la cadena de herramientas Mono, puede usar the < code> monodis utility con el argumento --assemblyref para enumerar las dependencias de un ensamblado .NET. Esto funcionará en los archivos .exe y .dll .

Ejemplo de uso: 

monodis --assemblyref somefile.exe

Salida de ejemplo (.exe): 

$ monodis --assemblyref monop.exe
AssemblyRef Table
1: Version=4.0.0.0
    Name=System
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89
2: Version=4.0.0.0
    Name=mscorlib
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89

Salida de ejemplo (.dll): 

$ monodis --assemblyref Mono.CSharp.dll
AssemblyRef Table
1: Version=4.0.0.0
    Name=mscorlib
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89
2: Version=4.0.0.0
    Name=System.Core
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89
3: Version=4.0.0.0
    Name=System
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89
4: Version=4.0.0.0
    Name=System.Xml
    Flags=0x00000000
    Public Key:
0x00000000: B7 7A 5C 56 19 34 E0 89

Habilitar el registro de enlace de ensamblaje establezca el valor de registro EnableLog en HKLM \ Software \ Microsoft \ Fusion en 1. Tenga en cuenta que debe reiniciar su aplicación (use iisreset) para que los cambios tengan algún efecto.

Sugerencia: recuerde desactivar el registro de fusión cuando termine, ya que hay una penalización en el rendimiento al activarlo.

Es gracioso, tuve un problema similar y no encontré nada adecuado y estaba al tanto del viejo Dependency Walker, así que al final lo escribí yo mismo.

Esto se ocupa de .NET específicamente y mostrará qué referencias tiene (y falta) recursivamente un ensamblaje. También mostrará las dependencias de la biblioteca nativa.

Es gratis (para uso personal) y está disponible aquí para cualquier persona interesada: www.netdepends.com

www.netdepends.com

Bienvenida de comentarios.

http://www.amberfish.net/

ChkAsm le mostrará todas las dependencias de un conjunto en particular a la vez, incluidas las versiones, y le permitirá buscar fácilmente los conjuntos en la lista. Funciona mucho mejor para este propósito que ILSpy ( http://ilspy.net/ ), que es lo que solía usar para esta tarea.

Otro complemento útil de Reflector que utilizo es la Matriz de estructura de dependencia . Es realmente genial ver qué clases usan qué. Además es gratis.

Intente compilar su ensamblaje .NET con la opción --staticlink: " Namespace.Assembly " . Esto obliga al compilador a jalar todas las dependencias en tiempo de compilación. Si se encuentra con una dependencia a la que no se hace referencia, aparecerá un mensaje de advertencia o error, generalmente con el nombre de ese ensamblaje.

Namespace.Assembly es el conjunto que sospecha que tiene el problema de dependencia. Normalmente, solo el enlace estático de este ensamblaje hará referencia a todas las dependencias de forma transitiva.

La mejor aplicación que veo y uso, muestra las dlls perdidas / problemáticas: http://www.dependencywalker.com/

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top