I have the following test environment: An EXE application that references a
DLL library. No further references other than the framework. Both files are
in the same directory, but not in the current working directory. The EXE
file defines a class that inherits from a class defined in the DLL. I need
to open all assemblies and investigate their types, base types etc. I have
opened both files like this:
// Instance member, used for all files to read
private IAssemblyResolver asmResolver = new DefaultAssemblyResolver();
// Read a file
((DefaultAssemblyResolver)
asmResolver).AddSearchDirectory(Path.GetDirectoryName(fileName));
var moduleDef = ModuleDefinition.ReadModule(fileName, new
ReaderParameters() { AssemblyResolver = asmResolver });
The EXE file comes first, then the DLL. Even if it would work the other way
around, this is a scenario that needs to work as I can't figure out the
referencing hierarchy all the time. The call to AddSearchDirectory makes
Cecil find the referenced library at all, a thing I'd have expected out of
the box, since at runtime it's the same. But I have the impression that I
get two independent instances of the DLL assembly. One that I know of any
investigate, and another one that Cecil uses internally as reference for
the EXE file. I thought that using a common resolver instance should help,
but it doesn't seem to be the case.
It's really hard to figure out how to use this stuff if there's no
documentation at all. It's been a guesswork from the start and now I'm
stuck.
Even if I need to write my own code for the assembly resolver, what should
it do? There's an interface, but it comes with no meaning, only method
names.
--
--
--
mono-cecil
---
You received this message because you are subscribed to the Google Groups
"mono-cecil" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
