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

¿Cómo determino las dependencias de una aplicación .NET? ¿ Dependency Walker funciona con aplicaciones administradas? Descargué la última versión y probé la creación de perfiles de la aplicación, pero se acaba sin demasiada explicación. Si no funciona con .NET, ¿hay alguna otra herramienta que me ayude a depurar un problema de carga DLL en tiempo de ejecución?

Dependency walker funciona en binarios win32 normales. Todos .NET dll y exe tienen una pequeña parte del encabezado stub que los hace parecer binarios normales, pero todo lo que básicamente dice es “cargar el CLR”, así que eso es todo lo que el caminante de dependencias le dirá.

Para ver en qué cosas confía su aplicación .NET, puede usar el tremendamente excelente reflector .NET de Red Gate. (EDITAR: Tenga en cuenta que .NET Reflector es ahora un producto pago. ILSpy es gratuito y de código abierto y muy similar.)

Carga tu DLL en él, haz clic con el botón derecho y elige “Analizar”: verás un elemento “Depende de” que te mostrará todos los otros dll (y los métodos dentro de esos dll) que necesita.

Sin embargo, a veces puede ser más complicado, ya que su aplicación depende de X dll, y X dll está presente, pero por alguna razón no se puede cargar o ubicar en tiempo de ejecución.

Para solucionar este tipo de problemas, Microsoft tiene un Visor de registro vinculante de ensamblaje que puede mostrarle lo que está sucediendo en tiempo de ejecución

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

Ejecútelo en un símbolo del sistema en el directorio de .dll con los siguientes argumentos:

 asmspy . all 

captura de pantalla de la salida asmspy

Instalarlo rápidamente con Chocolatey:

 choco install asmspy 

Abra el archivo de ensamblaje en ILDASM y busque @. El ensamblado extern en MANIFEST

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

  • un gráfico de dependencia
  • una matriz de dependencia ,
  • y también se pueden editar (o generar) algunas consultas C # LINQ para explorar las dependencias.

Por ejemplo, tal consulta puede verse así:

 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 profundidad métrica del código, 1 es para personas que llaman directamente, 2 para llamadas de personas que llaman directamente …) (observe también el botón Exportar a gráfico para exportar el resultado de la consulta a un gráfico de llamadas )

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

El gráfico de dependencia se ve así:

NDependen el gráfico de dependencia

La matriz de dependencia se ve así:

NDepender de la matriz de dependencia

La matriz de dependencia es de facto menos intuitiva que el gráfico, pero es más adecuada para explorar secciones complejas de código como:

NDepender matriz frente a gráfico

Descargo de responsabilidad: trabajo para NDepend

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

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

Si está utilizando la herramienta de herramientas Mono, puede usar la utilidad monodis 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 

Ejemplo de salida (.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 

Ejemplo de salida (.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 

Habilite el registro de enlace de conjunto 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.

Consejo: Recuerde desactivar el registro de fusión cuando haya finalizado, ya que existe una penalización de rendimiento para activarlo.

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

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

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

www.netdepends.com

Comentarios bienvenidos.

http://www.amberfish.net/

ChkAsm le mostrará todas las dependencias de un ensamblaje en particular a la vez, incluidas las versiones, y le permitirá buscar ensamblajes fácilmente 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 útil complemento de Reflector que uso es la Matriz de Estructura de Dependencia . Es realmente genial ver qué clases usan qué. Además es gratis.

Intente comstackr su ensamblado .NET con la opción --staticlink:"Namespace.Assembly" . Esto obliga al comstackdor a incorporar todas las dependencias en el momento de la comstackción. Si se trata de una dependencia a la que no se hace referencia, dará un mensaje de advertencia o error generalmente con el nombre de ese ensamblado.

Namespace.Assembly es el conjunto que usted sospecha que tiene el problema de dependencia. Típicamente, la vinculación estática de este conjunto hará referencia a todas las dependencias transitoriamente.

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