What is, or should I ask, is there, an equivalent to DllMain when creating a dll using C++\CLI?
Are there any restrictions on what cannot be called from this initialization code?
A:
If you're using the dll in another managed project (a c# application for example), you don't need to do anything... As long as the classes you try to access are ref classes, you can access them from any other managed application.
shash
2008-12-12 06:03:00
A:
One giant advantage of .Net dlls is that they avoid the loader lock. One side effect is that there's no DllMain.
Windows programmer
2008-12-12 06:29:13
how do they avoid the loader lock? if the need to load a native dll couldn't that cause a loader lock?
DanJ
2008-12-13 20:05:27
Loading a .Net dll avoids the loader lock because a .Net dll isn't a native dll. Loading a native dll would contend for the loader lock because a native dll is a native dll.
Windows programmer
2008-12-15 02:38:12
These comments only apply when compiling with /clr:pureSimply /clr by itself creates a mixed library, containing both native and managed code, and the native part will have a DllMain that runs under loader lock.
Ben Voigt
2010-02-06 18:39:24
+1
A:
Dan: With respect to the loader lock, C++/CLI's delay load of the CLR and proper initialization for a mixed mode binary, I just posted yesterday on the subject here.
More or less, if you have a mixed mode binary, you must not cause any managed code to run while you are in DllMain().
RandomNickName42
2009-05-19 19:45:49
+2
A:
Since .NET 2.0 you have a "module initializer". See here for more information on how that solves the loader lock problem and also here
For a direct answer to your question, this page quotes the standard which says: "There are no limitations on what code is permitted in a module initializer. Module initializers are permitted to run and call both managed and unmanaged code."
Ben Voigt
2010-02-06 18:43:00