3

I've added a hosting interface to a native C++ application which instantiates the CLR, creates a custom appDomainManager, and provides calls to load managed assemblies into the native process. In my native C++ LoadDLL() function I was expecting to be able to test the incoming dll for .net vs C++ by calling LoadLibrary(dllPath) which I assumed would return failure (NULL) for managed assemblies, but I'm finding that it is returning a handle instead (this is with no CLR currently running in the unmanaged process). Is this normal behavior for an unmanaged LoadLibrary() call on a managed assembly?

I'm not sure I understand how LoadLibrary can even find a proper entry point to test in a managed assembly. I know (one possible) way to solve the problem, and the way I'm planning to implement, is simply to use the CLR instance to access the .net reflection APIs and check if the DLL is managed there first...but I'm puzzled by the fact that LoadLibrary() isn't returning failure and I'd like to understand what I'm missing here. Is the behavior undefined, should it always return a handle, or does it depend on the configuration of the managed assembly? Any link to references is appreciated.

Edit:

Question answered in comments, closing.

NAW
  • 95
  • 9
  • A .NET assembly looks just like a normal DLL to Windows. So LoadLibrary works fine. It it what you normally do next, calling GetProcAddress() to find an entry point in the DLL that doesn't work. A pure managed .NET assembly doesn't have any. So don't use LoadLibrary, it is pointless. Lots and lots of [sample code](http://support.microsoft.com/kb/953836) around to show you how to use the _AppDomain interface. – Hans Passant Aug 01 '13 at 01:20
  • Thanks for the response. I already have the _AppDomain interface implemented and working, I was just curious why LoadLibrary wasn't failing on a .net assembly and wanted to verify the normal behavior. Doesn't it seem strange that the call succeeds on an assembly that it can't actually perform any useful actions on? Is this just a funky logic hole or is there some other use for loading a managed assembly into an unmanaged process that I'm not aware of? – NAW Aug 01 '13 at 14:45
  • 1
    No, that's not strange. A .NET assembly can also contain unmanaged code so calling LoadLibrary + GetProcAddress is perfectly reasonable for such an assembly. There is no special feature built into Windows that forbids calling LoadLibrary when the DLL has no exported functions. A DLL that just contains resources is perfectly valid for example. – Hans Passant Aug 01 '13 at 15:00
  • @HansPassant what about C++ managed dll.can it be used along with LoadLIbrary in c++ application. – Vikram Ranabhatt Jun 28 '14 at 09:07

1 Answers1

1

No, they won't do anything, the dll/exe of managed program is just a stub(stub means template but essential) program that will attempt to call mscoree, which is the .Net runtime executor, also called the shim, because it would attempt to select the version of .net framework(and the native function name is called _CorExeMain), then the shim itself will bootstrap the .Net framework, and launch a clr instance, then start the procession of IL codes inside the PE, besides that it's just some metadata generated by the CIL compiler, such as resource pools(string pool, constant values), function prototypes, inheritance, and generics types.

For more information, take a deep look at this: http://blog.vuscode.com/malovicn/archive/2007/12/25/net-foundations-net-execution-model.aspx , You won't be disappointed.

Steve Fan
  • 3,019
  • 3
  • 19
  • 29