When to initialize managed wrappers in mixed mode

[Hugh Williams]

I have a mixed-mode DLL doing some SSPI stuff that needs to support a web
service.

The article at http://support.microsoft.com/?id=814472 says you need to
manually initialize the CRT when doing mixed-mode work.

The only method I need to call in the mixed-mode DLL is a single, static
method of one class.

Do I need to manually initialize the CRT every time I call into that DLL, or
can I just do it once when the web service starts?

[Tomas Restrepo \(MVP\)]

Hugh,

I have a mixed-mode DLL doing some SSPI stuff that needs to support a web
service.

The article at http://support.microsoft.com/?id=814472 says you need to
manually initialize the CRT when doing mixed-mode work.

The only method I need to call in the mixed-mode DLL is a single, static
method of one class.

Do I need to manually initialize the CRT every time I call into that DLL, or can I just do it once when the web service starts?

You *should* do it only once (as that should initialize the CRT for the
lifetime of the DLL), and then uninitialize it before it is unloaded (such
as when the application is going down).

--
Tomas Restrepo
to****@mvps.org

[Hugh Williams]

Thanks Tomas --

One follow-up... I'm not too deep in my understanding of how DLLs get loaded
and the dynamics of CRT initialization:

If the process that loads my DLL (in my case, an instance of aspnet_wp.exe)
has already initialized the CRT because of something else that's going on,
do I need to do it again? Put another way, is the CRT initialized on a
per-DLL or per-process basis?

Thanks again.
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hugh,

I have a mixed-mode DLL doing some SSPI stuff that needs to support a web
service.

The article at http://support.microsoft.com/?id=814472 says you need to
manually initialize the CRT when doing mixed-mode work.

The only method I need to call in the mixed-mode DLL is a single, static
method of one class.

Do I need to manually initialize the CRT every time I call into that DLL, or can I just do it once when the web service starts?

You *should* do it only once (as that should initialize the CRT for the
lifetime of the DLL), and then uninitialize it before it is unloaded (such
as when the application is going down).

--
Tomas Restrepo
to****@mvps.org

[Tomas Restrepo \(MVP\)]

Hi Hugh,

One follow-up... I'm not too deep in my understanding of how DLLs get loaded and the dynamics of CRT initialization:

If the process that loads my DLL (in my case, an instance of aspnet_wp.exe) has already initialized the CRT because of something else that's going on,
do I need to do it again? Put another way, is the CRT initialized on a
per-DLL or per-process basis?

Great question, and not exactly too easy to answer. The basic answer is, it
depends!

If you take .NET out of the picture, the answer would still be "it depends".
Why? Because there might be multiple copies of the CRT on a single process,
as it all depends on your linking options. If you have modules that are
statically linked against the CRT, then each one of those modules will have
it's own copy of the CRT. Those that are linked to the DLL version of the
CRT, on the other hand, will share the CRT.
That said, each copy of the CRT is usually initialized either from the .exe
as it loads, or for dll modules from within DllMain as it is loaded. I'm not
fully aware of all the details (but could be checked by looking at the CRT
source code), even for modules linked to the MSVCRTXX.DLL, you still need
per-module initialization of the DLL (even though, conceptually, they are
using the same CRT instance). The reason might be just that initializing the
CRT does far more than just initialize it's internal structures, but also
ensures some language features work, such as initializing static global
objects, for example (which is clearly module-specific).

These basic rules don't change just because you bring .NET into the mix. It
just gets more complex for mixed-mode dlls because of the loader-lock issue.

--
Tomas Restrepo
to****@mvps.org