CODEWITHSUNDEEP
.net
toddmo
toddmo

Reputation: 22466

Finding the DLLs that are actually used vs the ones that are referenced

I have a need to identify only the dlls that are used. Let me explain.

If you have a .Net exe, MyEXE.exe, for example, that references DLLA.dll, and DLLA.dll is a library of common functions that references 17 other DLLs, then during the build .Net will put all 17 along with DLLA.dll in the MyEXE.exe's bin folder. Even if MyEXE.exe only calls code that is used in 2 of the dlls referenced by DLLA.dll.

A .net app will run just fine with missing dlls as long as the entry assembly does not directly or indirectly call any functionality in the missing dll.

So I want to find the ones which are used.

I don't want to hard code this per project, thanks. I'd like an algorithm that I can run on any project. Thanks.

Upvotes: 1

Views: 70

Answers (1)

JaredPar
JaredPar

Reputation: 755447

This isn't really a solvable problem in .Net. The general case is straight forward and is described by the following algorithm:

  • Put every method in MyEXE into the "must inspect list"
  • While there are methods in the "must inspect list"
    • Add the assembly containing the type which declares the method to the "needed set"
    • Repeat for all super types
    • Scan through the body looking for all referenced methods. Add these to the "must inspect list"

This will put all of the actual needed assemblies into the "needed set".

This is a fairly exhaustive search but misses a number of items

  • Static constructors
  • Reflection
  • WPF bindings
  • Activator.CreateInstance
  • etc ...

All of these represent dynamic method calls which can't realistically be analyzed by a static checker. Any of these could cause one of the other 17 DLLs to be used and hence break your deployment.

Instead of trying to statically detect the necessary set of assemblies (unsolvable) I would try and refactor the code so that the needed subset doesn't bring in so many DLLs

Upvotes: 1

Related Questions