how to programatically identify a file as a .NET assembly?

  • Thread starter Thread starter Emby
  • Start date Start date
E

Emby

Hello ...

Is there an easy/quick - or at least reasonable - way to programmatically
identify a .NET assembly (EXE or DLL). My app needs to look in a set of
folders and find which files are .NET assemblies. Some of the folders
contain many files (>100) with 1 or 2 assemblies among them.

Is there a way to readily find the assemblies? - other than the brute force
mechanism of trying to load each file as an assembly and handling the many
errors ... :-)

Thanks!
 
Hello, Emby!
You wrote on Thu, 14 Sep 2006 15:25:09 -0400:

E> Is there an easy/quick - or at least reasonable - way to
E> programmatically identify a .NET assembly (EXE or DLL). My app needs to
E> look in a set of folders and find which files are .NET assemblies. Some
E> of the folders contain many files (>100) with 1 or 2 assemblies among
E> them.

E> Is there a way to readily find the assemblies? - other than the brute
E> force mechanism of trying to load each file as an assembly and handling
E> the many errors ... :-)

Have a look at
( http://blogs.msdn.com/junfeng/archive/2004/02/06/68334.aspx )
 
Thanks Vadym,

That helped, but I found an even better way:
http://msdn.microsoft.com/msdnmag/issues/04/05/NETMatters/
(see figure 3, "Determining if a Portable Executable is Managed")

This shows an algorithm that looks at the PE file header. My experience with
it so far is that it is very fast, but it will mistakenly identity a few
files as managed that can not be loaded (about 97% accurate). But this
combined with Reflection.Assembly.ReflectionOnlyLoadFrom seems to work very
well.

That is, "Reflect load" only the files that pass the algorithm's IsManaged
test, and toss out those that can't be loaded. This weeds out the few wrong
ones, and is still quite fast (much faster than "reflect loading" all
files).

Cheers,
 
Back
Top