Як визначити залежності програми .NET? Чи працює Walker залежностей із керованими додатками? Я завантажив останню версію і спробував профайлювати додаток, але він просто закінчується без особливих пояснень. Якщо він не працює з .NET, чи є якийсь інший інструмент, який допоможе мені налагодити проблему з завантаженням DLL під час роботи?

Утримувач залежностей працює на звичайних бінарних файлах win32. У всіх .NET dll та exe є невелика частина заголовка заглушки, яка робить їх схожими на звичайні бінарні файли, але все, що в основному говорить, - це "завантажити CLR" - так це все, що ходити залежність скаже вам.

Щоб побачити, на що насправді покладається ваш додаток .NET, ви можете використовувати надзвичайно чудовий відбивач .NET від Red Gate. (EDIT: Зауважте, що .NET Reflector зараз є платним продуктом. ILSpy є безкоштовним та відкритим кодом та дуже подібним.)

Завантажте в нього DLL, клацніть правою кнопкою миші та оберіть "Аналіз" - тоді ви побачите пункт "Залежить від", який покаже вам всі інші DLL (та методи всередині цих DLL), які йому потрібні.

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

Для усунення таких проблем у Microsoft є переглядач журналів прив'язки анотації, який може показати вам, що відбувається під час виконання

Я вважаю невелику утиліту AsmSpy безцінним інструментом для вирішення проблем із завантаженнями. У ньому перераховані всі посилання на керовані збори, включаючи версії монтажу.

Запустіть його в командному рядку в каталозі .dllз наступними аргументами:

asmspy . all

Встановіть його швидко за допомогою Chocolatey:

choco install asmspy

Відкрийте файл складання в ILDASM і подивіться @ .assembly зовнішній вигляд у MANIFEST

Для перегляду залежностей від коду .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 - для прямих абонентів ...) (також зверніть увагу на кнопку Експортувати в графік, щоб експортувати результат запиту на графік викликів )

Графік залежності виглядає так:

Матриця залежності виглядає так:

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

Відмова: Я працюю на 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), щоб зміни мали будь-який ефект.

Порада: Не забудьте вимкнути реєстрацію термоядерних синтезів після завершення роботи, оскільки передбачено покарання за продуктивність.

Смішно, що у мене був подібний випуск, і я не знайшов нічого підходящого, і знав про старого доброго ходака за залежність, тож врешті-решт я написав його сам.

Це стосується конкретно .NET і покаже, які посилання на збірку мають (і відсутні) рекурсивно. Він також покаже залежність від рідної бібліотеки.

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

Відгуки Ласкаво просимо.

http://www.amberfish.net/

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

Ще одна зручна надбудова Reflector, яку я використовую, - це матриця структури залежності . Дійсно чудово бачити, які класи використовують для чого. Плюс це безкоштовно.

Спробуйте скласти свою збірку .NET за допомогою параметра --staticlink:"Namespace.Assembly". Це змушує компілятора витягнути всі залежності за час компіляції. Якщо вона наштовхується на залежність, на яку не посилається, вона видаватиме попередження або повідомлення про помилку, як правило, з назвою цієї збірки.

Namespace.Assemblyце збірка, яку ви підозрюєте, що має проблему залежності. Зазвичай просто статичне з'єднання цієї збірки посилається на всі залежності перехідно.

Кращий додаток, який я бачу та використовую, показує пропущені / проблемні dlls: http://www.dependencywalker.com/