Geek Answers Handbook

How to get a programmatic list of all downloaded assemblies (link) in the .NET Compact Framework

I am running Windows CE and using the Compact Framework. I need to get a list of all the referenced assemblies downloaded by my application. It would be nice to have access to the AssemblyName (object) of these assemblies.

An example such as getting my current assembly by doing: Assembly.GetExecutingAssembly (); except that I need to get a link to all other downloaded assemblies (third-party Dlls).

The full structure has the Assembly.GetExecutingAssembly () method . GetReferencedAssemblies () , but it is not available in the Compact Framework. Any help would be appreciated.

+4
c # windows-ce compact-framework assemblies
source share
2 answers

Based on this , it seems that the managed dll is not really loaded in the sense that they are in a regular structure. Instead, IL maps the memory and the JIT just grabs what it needs when it goes (saving the need to support memory loading for code that has been executed but is no longer in use).

This explains why CF makes it impossible to iterate over loaded DLLs. As for why it doesn't allow iteration over reference dlls , which are a completely complex time construct ...

As possible work:
Use GetExecutingAssembly to get the active code. Make sure this happens in your executable, so it gets the root assembly.

Write some code that can analyze the DLL for a manifest indicating which assemblies are referenced (this is not necessarily managed code - the unmanaged introspective API microsoft API can even do this for you, and the dll format specification is publicly available and is unlikely to change dramatically in the near future ) I suggest a black dll listing downloaded from the GAC (although this may be unnecessary).

+4
source share

I think if there is no API for this, you can try this ...

Remember that this is not a good way to do this ...

  • Look for PInvoke calls in Windows CE and call them to find out which DLLs the process is loading.

  • Then iterate through the dll to check if they have a CLI header. Or you can just try loading the DLL as an assembly, if it is loading, then this is the .NET assembly loaded by the application.

I know this is not the right way to do this, but it might work.

0
source share

More articles:


All Articles