Как определить зависимости приложения .NET?

Question

Как определить зависимости приложения .NET? Работает ли Dependency Walker с управляемыми приложениями? Я скачал последнюю версию и попробовал профилировать приложение, но оно просто выходит без особых объяснений. Если он не работает с .NET, есть ли другой инструмент, который помог бы мне отладить проблему загрузки DLL во время выполнения?

Answer 1

Ходок зависимостей работает на обычных двоичных файлах win32. Все .NET dll и exe имеют небольшую часть заглушки заглушки, которая делает их похожими на обычные двоичные файлы, но все, что в основном говорит «загрузить CLR» - так это все, что вам скажет обходчик зависимостей.

Чтобы увидеть, на что действительно опирается ваше приложение .NET, вы можете использовать потрясающе превосходный .NET рефлектор от Red Gate. (РЕДАКТИРОВАТЬ: обратите внимание, что .NET Reflector теперь является платным продуктом. ILSpy является бесплатным и открытым исходным кодом и очень похож на него.)

Загрузите вашу DLL в нее, щелкните правой кнопкой мыши и выберите «Анализ» - вы увидите элемент «Зависит от», который покажет вам все остальные библиотеки DLL (и методы внутри этих библиотек DLL), в которых он нуждается.

Иногда это может быть сложнее, поскольку ваше приложение зависит от X dll, и X dll присутствует, но по какой-либо причине не может быть загружен или расположен во время выполнения.

Для устранения подобных проблем у Microsoft есть Просмотр журнала привязки сборки , который может показать вам, что происходит во время выполнения

Answer 2

Я считаю небольшую утилиту AsmSpy неоценимым инструментом для решения проблем с загрузкой сборок. В нем перечислены все ссылки на сборки управляемых сборок, включая версии сборок.

Запустите его в командной строке в каталоге .dll со следующими аргументами:

asmspy . all

Установите его быстро с Chocolatey:

choco install asmspy

Answer 3

Откройте файл сборки в ILDASM и посмотрите @ .assembly extern в МАНИФЕСТЕ

Answer 4

Для просмотра зависимостей кода .NET вы можете использовать возможности инструмента NDepend. Инструмент предлагает:

• a график зависимостей
• a матрица зависимостей ,
• , а также некоторые C # LINQ-запросы могут быть отредактированы (или сгенерированы) для просмотра зависимостей.

Например, такой запрос может выглядеть так:

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 }

И его результат выглядит следующим образом: (обратите внимание, метрика кода глубина , 1 - для прямых абонентов, 2 - для абонентов прямых абонентов ...) (обратите внимание также на кнопку «Экспорт в график» для экспорта запроса результат для Call Graph )

График зависимостей выглядит следующим образом:

Матрица зависимостей выглядит следующим образом:

Матрица зависимостей де-факто менее интуитивна, чем график, но она больше подходит для просмотра сложных участков кода, таких как:

Отказ от ответственности: я работаю на NDepend

Answer 5

Вам не нужно загружать и устанавливать условно-бесплатные приложения или инструменты. Вы можете сделать это программно из .NET, используя Assembly.GetReferencedAssemblies()

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

Answer 6

Если вы используете цепочку инструментов Mono, вы можете использовать утилиту monodis с аргументом --assemblyref для отображения зависимостей сборки .NET. Это будет работать как с .exe, так и с .dll файлами.

Пример использования:

monodis --assemblyref somefile.exe

Пример вывода (.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

Пример вывода (.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

Answer 7

Забавно, у меня была похожая проблема, я не нашел ничего подходящего и знал о старом добром Dependency Walker, так что в конце концов я написал один сам.

Это относится конкретно к .NET и покажет, какие ссылки есть (и отсутствуют) в сборке рекурсивно. Также будут показаны родные библиотечные зависимости.

Это бесплатно (для личного пользования) и доступно здесь для всех, кто заинтересован: www.netdepends.com

Обратная связь приветствуется.

Answer 8

Включить ведение журнала привязки сборки, установите значение реестра EnableLog в HKLM \ Software \ Microsoft \ Fusion равным 1. Обратите внимание, что вам необходимо перезапустить приложение (используйте iisreset), чтобы изменения имели какой-либо эффект.

Подсказка: Не забудьте отключить ведение журнала Fusion, когда закончите, так как есть снижение производительности за его включение.

Answer 9

http://www.amberfish.net/

ChkAsm покажет вам все зависимости конкретной сборки одновременно, включая версии, и легко позволит вам искать сборки в списке Работает намного лучше для этой цели, чем ILSpy (http://ilspy.net/),, который я использовал для этой задачи.

Answer 10

Попробуйте скомпилировать сборку .NET с параметром --staticlink:"Namespace.Assembly". Это заставляет компилятор извлекать все зависимости во время компиляции. Если он обнаружит зависимость, на которую нет ссылки, он выдаст предупреждение или сообщение об ошибке, обычно с именем этой сборки.

Namespace.Assembly - это сборка, в которой вы подозреваете наличие проблемы с зависимостями. Обычно просто статическое связывание этой сборки будет транзитивно ссылаться на все зависимости.