Jak określić zależności aplikacji .NET? Czy Dependency Walker działa z aplikacjami zarządzanymi? Pobrałem najnowszą wersję i próbowałem profilować aplikację, ale po prostu wychodzi bez większego wyjaśnienia. Jeśli nie działa z .NET, to czy jest jakieś inne narzędzie, które pomogłoby mi w debugowaniu problemu z ładowaniem biblioteki DLL czasu wykonywania?

Dependency Walker działa na normalnych plikach binarnych win32. Wszystkie biblioteki DLL i pliki exe .NET mają niewielką część nagłówkową, która sprawia, że ​​wyglądają jak zwykłe pliki binarne, ale w zasadzie mówi tylko o „załadowaniu CLR” - więc to wszystko, co powie Ci walker zależności.

Aby zobaczyć, na czym polega Twoja aplikacja .NET, możesz skorzystać z niesamowicie doskonałego reflektora .NET firmy Red Gate. (EDYCJA: Zwróć uwagę, że .NET Reflector jest teraz produktem płatnym. ILSpy jest darmowy, open source i bardzo podobny).

Załaduj do niego bibliotekę DLL, kliknij prawym przyciskiem myszy i wybierz opcję „Analiza” - zobaczysz wtedy element „Zależy od”, który pokaże wszystkie inne biblioteki DLL (i metody wewnątrz tych bibliotek), których potrzebuje.

Czasami może to być trudniejsze, ponieważ Twoja aplikacja zależy od X dll, a X dll jest obecny, ale z jakiegokolwiek powodu nie można go załadować ani zlokalizować w czasie wykonywania.

Aby rozwiązać tego rodzaju problemy, firma Microsoft ma przeglądarkę dziennika powiązań zestawu, która może pokazać, co się dzieje w czasie wykonywania

Uważam, że małe narzędzie AsmSpy jest nieocenionym narzędziem do rozwiązywania problemów z ładowaniem zestawów. Zawiera listę wszystkich odniesień do zestawów zarządzanych, w tym wersji zestawów.

Uruchom go w wierszu polecenia w katalogu .dllz następującymi argumentami:

asmspy . all

Zainstaluj go szybko z Chocolatey:

choco install asmspy

Otwórz plik zespołu w ILDASM i zobacz @ .assembly extern w MANIFESTIE

Aby przeglądać zależności kodu .NET, można skorzystać z możliwości narzędzia NDepend. Narzędzie proponuje:

• wykresie zależność
• matrycy zależność ,
• a także niektóre zapytania C # LINQ można edytować (lub generować) w celu przeglądania zależności.

Na przykład takie zapytanie może wyglądać następująco:

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 }

A jego wynik wygląda następująco: (zwróć uwagę na głębokość metryki kodu , 1 jest dla bezpośrednich dzwoniących, 2 dla dzwoniących bezpośrednich ...) (zwróć także uwagę na przycisk Eksportuj do wykresu, aby wyeksportować wynik zapytania do wykresu połączenia )

Wykres zależności wygląda następująco:

Macierz zależności wygląda następująco:

Macierz zależności jest de facto mniej intuicyjna niż wykres, ale jest bardziej odpowiednia do przeglądania złożonych sekcji kodu, takich jak:

Zastrzeżenie: pracuję dla NDepend

Nie musisz pobierać ani instalować aplikacji ani narzędzi typu shareware. Możesz to zrobić programowo z .NET używającAssembly.GetReferencedAssemblies()

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

Jeśli używasz toolchain Mono, można skorzystać z monodisnarzędzia z --assemblyrefargumentem do listy zależności o .NET montaż. Będzie to działać zarówno na plikach, jak .exei .dll.

Przykładowe użycie:

monodis --assemblyref somefile.exe

Przykładowe dane wyjściowe (.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

Przykładowe dane wyjściowe (.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

Włącz rejestrowanie powiązań zespołu ustaw wartość rejestru EnableLog w HKLM \ Software \ Microsoft \ Fusion na 1. Należy zauważyć, że należy ponownie uruchomić aplikację (użyć iisreset), aby zmiany odniosły skutek.

Wskazówka: pamiętaj, aby wyłączyć rejestrowanie fuzji po zakończeniu, ponieważ włączenie go wiąże się z obniżeniem wydajności.

To zabawne, że miałem podobny problem i nie znalazłem nic odpowiedniego i byłem świadomy starego dobrego Dependency Walkera, więc ostatecznie napisałem jeden sam.

Dotyczy to w szczególności .NET i pokaże rekursywnie, jakie odwołania ma zestaw (i jakich brakuje). Pokaże również zależności bibliotek natywnych.

Jest bezpłatny (do użytku osobistego) i dostępny tutaj dla wszystkich zainteresowanych: www.netdepends.com

Opinie mile widziane.

http://www.amberfish.net/

ChkAsm pokaże wszystkie zależności określonego zestawu naraz, w tym wersje, i łatwo umożliwi wyszukiwanie zestawów na liście. Działa znacznie lepiej w tym celu niż ILSpy ( http://ilspy.net/ ), którego używałem do tego zadania.

Innym przydatnym dodatkiem Reflector, którego używam, jest Matryca Struktury Zależności . Wspaniale jest zobaczyć, jakie zajęcia wykorzystują czego. Dodatkowo to nic nie kosztuje.

Spróbuj skompilować zestaw .NET z opcją --staticlink:"Namespace.Assembly" . Zmusza to kompilator do ściągnięcia wszystkich zależności w czasie kompilacji. Jeśli napotka zależność, do której nie ma odwołania, wyświetli ostrzeżenie lub komunikat o błędzie, zwykle z nazwą tego zestawu.

Namespace.Assemblyjest zestawem, który podejrzewasz, że ma problem z zależnościami. Zwykle tylko statyczne łączenie tego zestawu będzie odwoływać się do wszystkich zależności przechodnie.

Najlepsza aplikacja, którą widzę i której używam, pokazuje pominięte / problematyczne pliki DLL: http://www.dependencywalker.com/