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

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

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

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

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

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

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

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

asmspy . all

Установите его быстро с помощью Chocolatey:

choco install asmspy

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

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

• граф зависимостей
• матрица зависимостей ,
• а также некоторые запросы 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 для вызывающих прямых звонков ...) (обратите внимание также на кнопку Export to Graph для экспорта результата запроса в Call Graph )

График зависимости выглядит так:

Матрица зависимостей выглядит так:

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

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

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

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

Если вы используете цепочку инструментов 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

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

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

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

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

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

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

http://www.amberfish.net/

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

Еще одна удобная надстройка Reflector, которую я использую, - это матрица структуры зависимостей . Действительно здорово видеть, какие классы что используют. Плюс это бесплатно.

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

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

Лучшее приложение, которое я вижу и использую, показывает пропущенные / проблемные DLL: http://www.dependencywalker.com/