Обходчик зависимостей работает с обычными двоичными файлами Win32. Все .NET dll и exe имеют небольшую часть заголовка-заглушки, которая делает их похожими на обычные двоичные файлы, но все, что он в основном говорит, это «загрузите CLR» - так что это все, что вам скажет этот обходчик зависимостей.
Чтобы увидеть, на что на самом деле опирается ваше .NET-приложение, вы можете использовать превосходный рефлектор .NET от Red Gate. (РЕДАКТИРОВАТЬ: обратите внимание, что .NET Reflector теперь является платным продуктом. ILSpy является бесплатным, с открытым исходным кодом и очень похож.)
Загрузите в нее свою DLL, щелкните правой кнопкой мыши и выберите «Анализировать» - после этого вы увидите пункт «Зависит от», который покажет вам все остальные библиотеки DLL (и методы внутри этих библиотек), которые ей нужны.
Иногда это может быть сложнее, поскольку ваше приложение зависит от X dll, а X dll присутствует, но по какой-либо причине не может быть загружен или размещен во время выполнения.
Для устранения таких проблем у Microsoft есть средство просмотра журнала привязки сборок, которое может показать вам, что происходит во время выполнения.
Я считаю небольшую утилиту AsmSpy бесценным инструментом для решения проблем с загрузкой сборок. В нем перечислены все ссылки на сборки управляемых сборок, включая версии сборок.
Запустите его в командной строке в каталоге
.dll
со следующими аргументами:Установите его быстро с помощью Chocolatey:
источник
Откройте файл сборки в ILDASM и посмотрите @ .assembly extern в МАНИФЕСТЕ
источник
Для просмотра зависимостей кода .NET вы можете использовать возможности инструмента NDepend. Инструмент предлагает:
Например, такой запрос может выглядеть так:
И его результат выглядит так: (обратите внимание на глубину метрики кода , 1 для прямых звонков, 2 для вызывающих прямых звонков ...) (обратите внимание также на кнопку Export to Graph для экспорта результата запроса в Call Graph )
График зависимости выглядит так:
Матрица зависимостей выглядит так:
Матрица зависимостей де-факто менее интуитивно понятна, чем граф, но она больше подходит для просмотра сложных участков кода, таких как:
Отказ от ответственности: я работаю в NDepend
источник
Вам не нужно загружать и устанавливать условно-бесплатные приложения или инструменты. Вы можете сделать это программно из .NET, используя
Assembly.GetReferencedAssemblies()
источник
[Reflection.Assembly]::LoadFile('C:\absolute\path\to\my.dll').GetReferencedAssemblies()
. Имеет приятное преимущество, заключающееся в том, что не нужно скачивать и не искать инструменты в неизвестных местах Windows. +1Если вы используете цепочку инструментов Mono, вы можете использовать эту
monodis
утилиту с--assemblyref
аргументом, чтобы перечислить зависимости сборки .NET. Это будет работать как.exe
с.dll
файлами, так и с файлами.Пример использования:
Пример вывода (.exe):
Пример вывода (.dll):
источник
Включить ведение журнала привязки сборки установите для параметра реестра 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/
источник