Scanning DLL dependencies from a C# executable

I work on a parallel build tool which builds (among lots of other things) windows programs of various types. One part of our tool which makes life alot easier for our users is the automatic dependency scanning of EXE and DLL files. This means that if a user says they want to run "bob.exe" for example, they don't have to worry about dependency problems when "bob.exe" get's distributed to other nodes in the build network. This is because we scan "bob.exe" work out what DLLs it needs and send them along with it.

On the whole this works well except when an EXE programatically loads a DLL. Then the dependency has to be ha开发者_Python百科rd coded into the users make file. One problem we've started to have recently is what to do about C# DLLs/EXEs. These seem to contain DLL references which are not part of the PE format. I presume the references are inside some kind of C# container and that the C# runtime just programmatically loads them when the C# runtime kicks into action.

Can anyone tell me what the best approach would be to scanning out these references at a binary level? My build tool is multiplatform and my PE scanner is currently written in Java for this reason. Therefore I can't rely on any of the .NET libraries. My PE scanner can already parse out all the sections in the PE file and I'm used to parsing out the section which contains side-by-side assembly information for C++ applications. I just need some pointers for what to do in the case of C# apps...

The format of .NET assemblies is defined by standard ECMA-335 "Common Language Infrastructure (CLI)", specifically "Partition II: Metadata Definition and Semantics", which is freely available for download. You can use that to write your own Java parser for them that would extract the references.

You can use (or take inspiration from) the pe-file-reader library:

This library reads .net assembly and .net module files (portable executable files; managed executables). .Net module and assembly files are stored according to the ECMA 335 standard.