views:

779

answers:

4

Background:

My C# application includes a plugin framework and generic plugin loader.

The plugin loader enumerates the application directory in order to identify plugin dlls (essentially it searches for *.dll at this time).

Within the same application directory is a native (Windows, non-.net) dll, which, indirectly, one of the plugin dlls depends upon.

The plugin loader blindly assumes that the native.dll is a .NET Assembly dll, simply because it only checks the file extension. When it attempts to load the native dll, an exception is thrown:

"Could not load file or assembly 'native.dll' or one of its dependencies. The module was expected to contain an assembly manifest."

I basically create a diagnostic report if plugin loading fails, so I'm trying to avoid having this log filled up with messages about not being able to load the native dll (which I don't even want to attempt).

The question:

Is there some .NET API call that I can use to determine whether a binary happens to be a .NET assembly so that I don't attempt to load the native dll at all?

Perhaps longer term I will move my plugins to a subdirectory, but for now, I just want a work around that doesn't involve hard-coding the "native.dll" name inside my plugin loader.

I guess I'm looking for some kind of static Assembly.IsManaged() API call that I've overlooked.... presumably no such API exists?

A: 

You could always wrap the DLL loading with a try/except block...

orip
Thanks. Yes, that's what I currently do. I just wanted to avoid even attempting to load it if it's not managed.
Mr. Wilby
+2  A: 

As orip suggested, you will want to wrap it in a try {} catch {} block - in particular, you want to be watching out for the BadImageFormatException

foreach (string aDll in dllCollection) 
{
  try 
  {
     Assembly anAssembly = Assembly.LoadFrom(aDll);
  }
  catch (BadImageFormatException ex)
  {
    //Handle this here
  }
  catch (Exception ex)
  {
    //Other exceptions (i/o, security etc.)
   }
}

Check out the other exceptions here http://msdn.microsoft.com/en-us/library/1009fa28.aspx

iAn
I could add an explicit check for this exception, but I'd prefer not to even attempt to load the dll in the first instance.I guess I'm looking for some kind of static Assembly.IsManaged() API call that I've overlooked.... presumably no such API exists?
Mr. Wilby
+3  A: 

How to determine whether a file is a .NET Assembly or not?

public static bool IsManagedAssembly(string fileName)
{
    uint peHeader;
    uint peHeaderSignature;
    ushort machine;
    ushort sections;
    uint timestamp;
    uint pSymbolTable;
    uint noOfSymbol;
    ushort optionalHeaderSize;
    ushort characteristics;
    ushort dataDictionaryStart;
    uint[] dataDictionaryRVA = new uint[16];
    uint[] dataDictionarySize = new uint[16];

    Stream fs = new FileStream(fileName, FileMode.Open, FileAccess.Read);
    BinaryReader reader = new BinaryReader(fs);

    //PE Header starts @ 0x3C (60). Its a 4 byte header.
    fs.Position = 0x3C;
    peHeader = reader.ReadUInt32();

    //Moving to PE Header start location...
    fs.Position = peHeader;
    peHeaderSignature = reader.ReadUInt32();

    //We can also show all these value, but we will be       
    //limiting to the CLI header test.
    machine = reader.ReadUInt16();
    sections = reader.ReadUInt16();
    timestamp = reader.ReadUInt32();
    pSymbolTable = reader.ReadUInt32();
    noOfSymbol = reader.ReadUInt32();
    optionalHeaderSize = reader.ReadUInt16();
    characteristics = reader.ReadUInt16();

    // Now we are at the end of the PE Header and from here, the PE Optional Headers starts... To go directly to the datadictionary, we'll increase the stream’s current position to with 96 (0x60). 96 because, 28 for Standard fields 68 for NT-specific fields From here DataDictionary starts...and its of total 128 bytes. DataDictionay has 16 directories in total, doing simple maths 128/16 = 8. So each directory is of 8 bytes. In this 8 bytes, 4 bytes is of RVA and 4 bytes of Size. btw, the 15th directory consist of CLR header! if its 0, its not a CLR file :)
    dataDictionaryStart = Convert.ToUInt16(Convert.ToUInt16(fs.Position) + 0x60);
    fs.Position = dataDictionaryStart;
    for (int i = 0; i < 15; i++)
    {
        dataDictionaryRVA[i] = reader.ReadUInt32();
        dataDictionarySize[i] = reader.ReadUInt32();
    }
    fs.Close();

    if (dataDictionaryRVA[14] == 0) return false;
    else return true;
}
lubos hasko
Thanks. That's kind of what I've been looking around on the NET for, but hadn't seen anybody trying to do it. Looks like it might be one approach.
Mr. Wilby
Yes, but keep in mind that this method is very verbose (you don't need half of it, really), it could get reduced down to three lines just to check for CLR header and skipping the rest.
lubos hasko
+1  A: 

I'm afraid the only real way of doing this is to call System.Reflection.AssemblyName.GetAssemblyName passing the full path to the file you want to check. This will attempt to pull the name from the manifest without loading the full assembly into the domain. If the file is a managed assembly then it will return the name of the assembly as a string otherwise it will throw a BadImageFormatException which you can catch and ignore before skipping over the assembly and moving onto your other plugins.

Wolfwyrd
Your approach sounds like it should be more lightweight than trying to load the entire dll, but I guess under the hood, the CLR is actually going to perform this same check so this might end up being redundant rather than just loading it and catching the BadImageFormatExcetion in any case?
Mr. Wilby
True, given that there's only a single native DLL (and this number isnt going to grow) you're as well just calling load and handling the exception
Wolfwyrd
Thanks. I'm going to go with a combination of all the approaches mentioned in this thread. Thank you all!
Mr. Wilby