2

Problem: Assume you have a machine on which some .NET assembly registers, loads, and/or runs correctly. This assembly may reference unmanaged DLLs via p/invoke, it may utilize COM objects, and it may actually be implemented in C++/CLI. How can you produce, in one automated step, a list of all the other DLLs (managed and unmanaged) that must be installed so that it will also register, load, and/or run on another machine?

Partial Solution #1: Red-gate's .net reflector can be used identify all the managed references.

Partial Solution #2: Red-gate's .net reflector has an "analyze" feature that will identify unmanaged DLLs utilized via p/invoke

Partial Solution #3: Depends can identify the unmanaged DLLs that are imported by an EXE or DLL. (And in its profiling mode, can also identify dynamic dependencies).

Open: How to run these tools (or others) in a batch mode, rather than manually clicking through all the dependency chains?

Bonus question: What about COM references -- is there any way to identify required COM objects and then also trace their dependencies?

Related Questions: I see that this question covers similar ground. (But it does not specify that unmanaged dependencies also be found, and the accepted answer is .net reflector which only provides part of what I'm looking for.) Similar for this one.

Community
  • 1
  • 1
Eric
  • 11,392
  • 13
  • 57
  • 100
  • I believe, all dependencies are located in the executable/assembly metadata. I'm afraid you'll have to start parsing PE headers to extract this information. Which isn't incredibly difficult once you understand the format. –  Dec 04 '10 at 04:19

1 Answers1

0

You simply cannot, at least not in a trustworthy manner. Install packages allow for things like placement of files, registry entries, and other actions to be performed on install.

Unless the project was XCOPY deployed, it's virutally impossible to figure out and guarantee what is required for a new proper install from what has been installed.

casperOne
  • 73,706
  • 19
  • 184
  • 253
  • Acknowledged -- I've changed the title and the problem statement to specify "DLLs" (which is what I meant) instead of "components" (which could be interpreted to mean files, registry entries, etc). – Eric Dec 04 '10 at 03:54