27

With Visual Studio, I can see the dll references as the attached picture as an example. With this reference information, I can open the (from the example) Composition project to find all the other references on and on to get all the reference file names.

Is there any utility that does this job automatically? I mean, given an .NET assembly, it checks all the references/dependencies recursively to give the names of DLLs.

I checked cygwin's ldd and Depends.exe, but they don't seem to show the dlls from other projects, but only system dlls.

enter image description here

prosseek
  • 182,215
  • 215
  • 566
  • 871
  • 2
    You could easily write one with Assembly.GetReferencedAssemblies(). Start at the EXE. Of course, you'll need to be able to *find* the assembly files, that can get quite hairy with .config files and publisher policies. The reason it isn't a universal utility. – Hans Passant Jan 05 '12 at 21:43
  • Related post - [Where does Visual Studio is referring the actual NuGet referenced DLL?](https://stackoverflow.com/q/50815222/465053) – RBT Jan 14 '20 at 00:53

5 Answers5

29

Yes: ildasm.exe. It is installed with the SDK.

Should be in a path like: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

competent_tech
  • 44,465
  • 11
  • 90
  • 113
  • but it only shows the native exern dlls. how to view the .net referenced assembblies? – Tiju John Sep 05 '13 at 12:51
  • 8
    If you double-click on the Manifest, it shows the .net referenced assemblies: .assembly extern System.Drawing { .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) // .?_....: .ver 4:0:0:0 } .assembly extern System.Data { .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4.. .ver 4:0:0:0 } – competent_tech Sep 05 '13 at 19:04
  • yes.. i got confused with http://stackoverflow.com/questions/18637173/how-is-the-net-referenced-assemblies-names-resolved-by-the-clr-at-runtime?noredirect=1#comment27463835_18637173 – Tiju John Sep 06 '13 at 08:03
15

I like to use AsmSpy for this type of check. There is a single exe to download and then I put it into my tools folder for easy access. https://github.com/mikehadlow/AsmSpy

Richard Edwards
  • 1,379
  • 1
  • 17
  • 30
  • 6
    +1 AsmSpy can produce (by using -dg key) an output file in *.dgml format which can be opened with Visual Studio 2013, or 2015. When opened in VS, **you can search it** (Ctrl-F) to find the dll of interest (for example a missing dll). Press "I" to select all dlls that depend on it. Then R-Click the graph/Select/Invert Selection, press Delete on your keyboard -- and you can get a nice readable graph of dlls dependent on a missing dll. Neither dotPeek, nor ILSpy (the heir of Reflector) could produce a list of dependencies in searchable format. – farfareast Dec 29 '16 at 22:54
9

You can use the provided ildasm.exe, or if you want something a little bit more powerfull, you can try:

Reflector

Even better, try the free:

dotPeek

Community
  • 1
  • 1
Gonza Oviedo
  • 1,312
  • 15
  • 20
1

This code will do a fairly good job at finding all the references. "temp" will be a dump of all the references it traced.

    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);
            }
        }
    }
Arrow
  • 29
  • 3
1

I don't know of any tools to do this automatically for you, but I can outline the steps any tool (or you) would have to follow.

Each assembly contains a manifest. The manifest lists the names and versions of all other assemblies that the current assembly depends upon. At its simplest you'd need to follow this trail recursively.

There's no correct way to tell you the filenames of the referenced assemblies. References are stored in the manifest as assembly names (name, version, culture, etc.) and not as filenames. When the .NET runtime needs to load a referenced assembly it uses various searches to find it, and the result of these searches may vary from environment to environment. Of course, this might not be a problem for you if you're just looking for the assemblies on your development machine, for example.

Techniques for resolving assembly references include searching any assemblies already loaded, looking in the Global Assembly Cache, looking in the application directory, redirecting based on application configuration files or publisher policies, and others. Google for the article "How the Runtime Locates Assemblies" in MSDN for more details. In addition, your application can register to do its own reference resolution by handling the System::AppDomain::AssemblyResolve event.

Ciaran Keating
  • 2,793
  • 21
  • 19