Yves,
interface IAssemblyResolver {
AssemblyDefinition Resolve (AssemblyNameReference reference);
}
This has no meaning? :)
A documentation would read like: An assembly resolver is responsible
for resolving references to an assembly into its definition.
(Which is arguably the same has the above, just a different language :)
You can also have a look at the default implementation:
https://github.com/jbevain/cecil/blob/master/Mono.Cecil/BaseAssemblyResolver.cs
https://github.com/jbevain/cecil/blob/master/Mono.Cecil/DefaultAssemblyResolver.cs
It's not a completely straightforward process, if you want a complete
understanding you can checkout and build Cecil in your project and
step into the code.
--
Now to answer your question.
The default resolver only caches the assemblies it resolves. Not those
you read yourself. Meaning, if you use ModuleDefiniton.ReadModule or
AssemblyDefinition.ReadAssembly, those won't be cached for you.
You can easily implement that by creating your own class extending
DefaultAssemblyResolver, and calling RegisterAssembly on existing
assemblies.
Jb
On Tue, Mar 25, 2014 at 8:07 PM, Yves Goergen <[email protected]> wrote:
> 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.
--
--
--
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.
