does .net dll have an entry point like dll in c++

问题:

I'm really not sure whether .net dll also have entry point like c++ dll generally have. How can i see if .net dll have entry point or not.

I read somewhere that a WIN32 dlls can have entry-points, dot-net class-libraries dont.

Thanks,

回答1:

It is an obscure subject, I'll go through it at breakneck speed. Every .NET assembly has an unmanaged entrypoint, 5 bytes of machine code (9 if built for x64) that serve as the entrypoint marked in the PE32 executable file header. Nothing but a JMP instruction, an EXE jumps to _CorExeMain() and a DLL jumps to _CorDllMain(). These functions are located in mscoree.dll and ensure that the CLR is loaded and initialized so it can execute managed code.

These entrypoints help to run managed program without having to start the VM host explicitly. Avoids the need for, say, mono.exe or java.exe. They are not actually used anymore on modern Windows versions, the OS has awareness of an executable file containing a .NET manifest and the loader passes the job to a loader shim, mscoree.dll again. This awareness is necessary to implement the considerable trick of erecting a 64-bit process out an EXE that contains a 32-bit PE32 header. Mscoree.dll patches internal loader data structures to accomplish this feat.

Each .NET assembly also contains a managed entrypoint, listed in the manifest header. Called by the CLR right after it loaded the assembly. An EXE always has one, it points to the Main() method and the compiler ensures that you can't forget to write one. A DLL might have one, a mixed-mode assembly always has one for example. Points to a module initializer located in the <Module> class, the C++/CLI compiler uses it to ensure that the CRT (C runtime library) is initialized before any managed code can execute.

回答2:

No, .NET DLL assemblies do not have a DllMain the way an unmanaged DLL would. However, all of the behaviors that one would implement in DllMain can generally be implemented using various .NET constructs. For example:

• A class static constructor gives you a chance to initialize static members before the type is used
• Instance initialization (constructor, field initializers) allow you to initialize instance data before the instance is used
• Implementing the IDisposable interface gives you deterministic cleanup. Implementing a finalizer gives you the possibility (but not the guarantee) of non-deterministic cleanup (i.e. before the object is garbage-collected)
• The AppDomain has the DomainUnload and ProcessExit events which can give you the chance to run cleanup code as the app domain or process is being closed.