2012-01-05 17 views
15

W Visual Studio widzę odniesienia do biblioteki dll jako załączony obraz jako przykład. Dzięki tym informacjom referencyjnym mogę otworzyć (z przykładu) projekt Composition, aby znaleźć wszystkie inne odniesienia w jednym miejscu, aby uzyskać wszystkie nazwy plików referencyjnych..Informacje DLL DLL/narzędzie sprawdzania zależności

Czy istnieje narzędzie, które wykonuje to zadanie automatycznie? Mam na myśli, biorąc pod uwagę zgromadzenia .NET, sprawdza rekurencyjnie wszystkie odniesienia/zależności, aby podać nazwy bibliotek DLL.

Sprawdziłem ldd cygwin i Depends.exe, ale nie wydają się one pokazywać biblioteki DLL z innych projektów, ale tylko biblioteki systemowe.

enter image description here

+1

Można łatwo napisać jedną z Assembly.GetReferencedAssembly(). Zacznij od EXE. Oczywiście będziesz musiał * znaleźć * pliki zespołu, które mogą stać się dość owłosione dzięki plikom .config i zasadom wydawcy. Powód, dla którego nie jest uniwersalnym narzędziem. –

Odpowiedz

19

Tak: ildasm.exe. Jest zainstalowany z SDK.

powinny być w jak ścieżka: C: \ Program Files (x86) \ Microsoft \ Windows SDK \ v7.0A \ Bin

+0

, ale pokazuje tylko natywne biblioteki DLL. jak wyświetlić podzespoły z odniesieniami .net? –

+5

Po dwukrotnym kliknięciu Manifestu wyświetlane są zespoły z odniesieniami .net: .assembly extern System.Drawing { .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A) //.? _....: .ver 4: 0: 0: 0 } .assembly zewnętrzny System.Data { .publickeytoken = (B7 7A 5C 56 19 34 89 E0) // .z \ .. .ver V.4 4: 0: 0: 0 } –

+0

tak .. mam mylić z http://stackoverflow.com/questions/18637173/how-is-the-net-referensed-semsemblies-names-resolved-by-the-clr-at -rodzime? noredirect = 1 # comment27463835_18637173 –

1

nie wiem o żadnych narzędzi, aby to zrobić automatycznie dla Ciebie, ale Potrafię opisać kroki, które musi wykonać każde narzędzie (lub Ty).

Każdy zestaw zawiera manifest. Plik manifestu zawiera nazwy i wersje wszystkich innych zespołów, od których zależy bieżący montaż. W najprostszym przypadku musisz podążać tą ścieżką rekurencyjnie.

Nie ma prawidłowego sposobu podawania nazw plików z odniesionych złożeń. Odnośniki są przechowywane w manifeście jako nazwy zespołów (nazwa, wersja, kultura itp.), A nie jako nazwy plików. Gdy środowisko wykonawcze .NET musi załadować zestaw referencyjny, używa różnych wyszukiwań, aby go znaleźć, a wyniki tych wyszukiwań mogą różnić się w zależności od środowiska. Oczywiście, może to nie być problemem dla ciebie, jeśli szukasz tylko złożeń na twoim komputerze programistycznym, na przykład.

Techniki rozwiązywania odniesień do zespołów obejmują wyszukiwanie wszystkich złoonych zestawów, przeglądanie w pamięci podręcznej zespołu globalnego, wyszukiwanie w katalogu aplikacji, przekierowanie na podstawie plików konfiguracyjnych aplikacji lub zasad wydawcy i innych. Google dla artykułu "Jak środowisko wykonawcze lokalizuje zestawy" w witrynie MSDN, aby uzyskać więcej informacji. Ponadto aplikacja może zarejestrować się, aby wykonać własne rozwiązanie referencyjne, posługując się zdarzeniem System :: AppDomain :: AssemblyResolve.

3

można użyć dostarczonego ildasm.exe, lub jeśli chcesz coś nieco większej wydajności, można spróbować:

Reflector

Jeszcze lepiej, spróbuj darmo:

dotPeek

Pozdrowienia,

1

Thi s kod wykona dość dobrą robotę przy znajdowaniu wszystkich referencji. "temp" będzie zrzutem wszystkich odnalezionych odniesień.

private void PerformReferenceAnalysis() 
    { 
     StringBuilder builder = new StringBuilder(); 
     HashSet<string> loadedAssemblies = new HashSet<string>(); 
     PerformReferenceAnalysis(System.Reflection.Assembly.GetExecutingAssembly(), builder, string.Empty, loadedAssemblies); 
     string temp = builder.ToString(); 
    } 

    private void PerformReferenceAnalysis(System.Reflection.Assembly assembly, StringBuilder builder, string leadingWhitespace, HashSet<string> loadedAssemblies) 
    { 
     if (builder.Length > 0) 
     { 
      builder.AppendLine(); 
     } 
     builder.Append(leadingWhitespace + assembly.FullName); 
     System.Reflection.AssemblyName[] referencedAssemblies = assembly.GetReferencedAssemblies(); 
     foreach (System.Reflection.AssemblyName assemblyName in referencedAssemblies) 
     { 
      if (loadedAssemblies.Contains(assemblyName.Name)) 
      { 
       continue; 
      } 
      loadedAssemblies.Add(assemblyName.Name); 
      System.Reflection.Assembly nextAssembly; 
      try 
      { 
       nextAssembly = System.Reflection.Assembly.ReflectionOnlyLoad(assemblyName.FullName); 
      } 
      catch (Exception) 
      { 
       try 
       { 
        nextAssembly = System.Reflection.Assembly.ReflectionOnlyLoad(assemblyName.Name); 
       } 
       catch (Exception) 
       { 
        nextAssembly = null; 
       } 
      } 
      if (nextAssembly != null) 
      { 
       PerformReferenceAnalysis(nextAssembly, builder, leadingWhitespace + "| ", loadedAssemblies); 
      } 
     } 
    } 
10

Lubię używać AsmSpy dla tego rodzaju czeku. Jest jeden exe do pobrania, a następnie umieszczam go w moim folderze narzędzi dla łatwego dostępu. https://github.com/mikehadlow/AsmSpy

+3

+1 AsmSpy może wytworzyć (używając klucza -dg) plik wyjściowy w formacie * .dgml, który można otworzyć za pomocą programu Visual Studio 2013 lub 2015. Po otwarciu w VS, ** możesz przeszukać go ** (Ctrl-F), aby znaleźć dll zainteresowania (na przykład brakującą dll). Naciśnij "I", aby wybrać wszystkie biblioteki dll, które zależą od niego. Następnie R-Kliknij wykres/Zaznacz/Odwróć wybór, naciśnij klawisz Delete na klawiaturze - i można uzyskać ładny czytelny wykres bibliotek zależnych od brakującej biblioteki dll. Ani dotPeek, ani ILSpy (dziedzic Reflectora) nie mogą tworzyć listy zależności w formacie umożliwiającym wyszukiwanie. – farfareast