Repost - Converting from pure mode to mixed mode Dll

[Edward Diener]

I received no answers about this the first time I posted, so I will try
again. My inability to decipher an MSDN topic may find others who have the
same inability and someone who can decipher and explain it.

I have some questions about the instructions for creating a mixed mode DLL
in the MSDN topic "Converting Managed Extensions for C++ Projects from Pure
Intermediate Language to Mixed Mode" in the "Managed Extensions for C++
Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is already set
up with this option in the linker, and the previous explanation about mixed
mode says "you must modify your DLL to have an explicit entry point". Is
this first instruction correct ?

2) I don't understand the three areas to consider for making further changes
under the topic "Modifying Components That Consume the DLL for Manual
Initializiation". I am creating a DLL as a "Class Library (.NET)" project. I
have not added in any DLL exports myself using __declspec(dllexport), and I
expect the end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry points as
opposed to the normal DllMain entry point in unmanaged code, but I have not
manually added a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding __DllMainCRTStartup@12 to
the Force Symbol References property. Do any of the three situations apply
to me, or can I just ignore the instructions in this section ? The last
possibility may apply,"Your DLL's consumers can use managed code, and your
DLL contains either DLL exports or managed entry points", so I want to know
if I have to implement the code mentioned in that solution, and then have a
console or Window program manually call my initialize and terminate static
member functions at the beginning and end of their main and WinMain
routines.

 

[Albert Szilvasy]

See below:

I received no answers about this the first time I posted, so I will try
again. My inability to decipher an MSDN topic may find others who have the
same inability and someone who can decipher and explain it.

I have some questions about the instructions for creating a mixed mode DLL
in the MSDN topic "Converting Managed Extensions for C++ Projects from Pure
Intermediate Language to Mixed Mode" in the "Managed Extensions for C++
Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is already set
up with this option in the linker, and the previous explanation about mixed
mode says "you must modify your DLL to have an explicit entry point". Is
this first instruction correct ?

[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid the
"loader lock" bug.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha
rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

2) I don't understand the three areas to consider for making further changes
under the topic "Modifying Components That Consume the DLL for Manual
Initializiation". I am creating a DLL as a "Class Library (.NET)" project. I
have not added in any DLL exports myself using __declspec(dllexport), and I
expect the end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry points as
opposed to the normal DllMain entry point in unmanaged code, but I have not
manually added a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding __DllMainCRTStartup@12 to
the Force Symbol References property. Do any of the three situations apply
to me, or can I just ignore the instructions in this section ?

[ALBERT:] #3 applies to you. Managed entry point in this context is simply
static or
instance method of managed type.

The last
possibility may apply,"Your DLL's consumers can use managed code, and your
DLL contains either DLL exports or managed entry points", so I want to know
if I have to implement the code mentioned in that solution, and then have a
console or Window program manually call my initialize and terminate static
member functions at the beginning and end of their main and WinMain
routines.

[ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify. Nevertheless,
the answer is yes.
Your clients will explictly have to call ManagedWrapper.minitialize() on
startup and ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

 

[Edward Diener]

See below:

I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and explain
it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?

[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha
rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me to make
a change when there was no necessity to do so, because the standard setup
for a pure mode .NET class library already has the /noentry flag set.

2) I don't understand the three areas to consider for making further
changes under the topic "Modifying Components That Consume the DLL
for Manual Initializiation". I am creating a DLL as a "Class Library
(.NET)" project. I have not added in any DLL exports myself using
__declspec(dllexport), and I expect the end-user of my Dll will use
it for the .NET components I have created. I also don't have any
idea what is meant by managed entry points as opposed to the normal
DllMain entry point in unmanaged code, but I have not manually added
a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding
__DllMainCRTStartup@12 to the Force Symbol References property. Do
any of the three situations apply to me, or can I just ignore the
instructions in this section ?

[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One usually
thinks of DllMain for DLLs, and WinMain or main for GUI and console apps, as
entry points. Now I understand that the term for "managed entry point" is
any .NET types methods.

The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call my
initialize and terminate static member functions at the beginning
and end of their main and WinMain routines.

[ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not ? I am
creating .NET components, so I assume my clients are either other .NET DLLs
or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call ManagedWrapper.minitialize()
on startup and ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET component
assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions from
within my own ones ? What prevents these routines from being called more
than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike a .NET
Windows Form application which does have a WinMain. Is there a reason to
have this with a mixed-mode DLL, or is it just completely unnecessary in
..NET assemblies ? If a pure mode assembly needs to initialize my assembly by
calling ManagedWrapper.minitialize and ManagedWrapper.mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about how one
tracks startup and shutdown in an assembly dll.

 

[Albert Szilvasy]

There's no such thing as assembly startup/shutdown. At least, this contract
is not standardized as it was with traditional dlls (i.e. DllMain). I
believe they looking at standardizing something similar but it doesn't
currently exist.

The client of your dll will have to call minitialize before they start using
any other functions in your dll and mterminate after they finished using
your dll.

Albert

See below:

I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and explain
it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link with
/NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?

[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me to make
a change when there was no necessity to do so, because the standard setup
for a pure mode .NET class library already has the /noentry flag set.

2) I don't understand the three areas to consider for making further
changes under the topic "Modifying Components That Consume the DLL
for Manual Initializiation". I am creating a DLL as a "Class Library
(.NET)" project. I have not added in any DLL exports myself using
__declspec(dllexport), and I expect the end-user of my Dll will use
it for the .NET components I have created. I also don't have any
idea what is meant by managed entry points as opposed to the normal
DllMain entry point in unmanaged code, but I have not manually added
a DllMain, if that is what is meant, other than following the
instructions to convert to mixed mode by adding
__DllMainCRTStartup@12 to the Force Symbol References property. Do
any of the three situations apply to me, or can I just ignore the
instructions in this section ?

[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One usually
thinks of DllMain for DLLs, and WinMain or main for GUI and console apps, as
entry points. Now I understand that the term for "managed entry point" is
any .NET types methods.

The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call my
initialize and terminate static member functions at the beginning
and end of their main and WinMain routines.

[ALBERT:] I'm a bit confused here because you said that you only have
managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not ? I am
creating .NET components, so I assume my clients are either other .NET DLLs
or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call ManagedWrapper.minitialize()
on startup and ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET component
assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions from
within my own ones ? What prevents these routines from being called more
than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike a .NET
Windows Form application which does have a WinMain. Is there a reason to
have this with a mixed-mode DLL, or is it just completely unnecessary in
.NET assemblies ? If a pure mode assembly needs to initialize my assembly by
calling ManagedWrapper.minitialize and ManagedWrapper.mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about how one
tracks startup and shutdown in an assembly dll.

 

[Edward Diener]

There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.

Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have to
do this, but there was no way I could create a pure mode component given the
C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look
at the great standard C++ string class, and attempt to create a string class
for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the
height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert

See below:
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and
explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.

2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That Consume
the DLL for Manual Initializiation". I am creating a DLL as a
"Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry
points as opposed to the normal DllMain entry point in unmanaged
code, but I have not manually added a DllMain, if that is what is
meant, other than following the instructions to convert to mixed
mode by adding __DllMainCRTStartup@12 to the Force Symbol
References property. Do any of the three situations apply to me,
or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.

The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call
my initialize and terminate static member functions at the
beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.

 

[Ronald Laeremans [MSFT]]

It isn't that different from components using COM though who also had to
init COM after DLL init and uninitialize before existing.

Ronald Laeremans
Visual C++ team

There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.

Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have to
do this, but there was no way I could create a pure mode component given the
C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look
at the great standard C++ string class, and attempt to create a string class
for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the
height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert

Albert Szilvasy wrote:
See below:
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and
explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.


2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That Consume
the DLL for Manual Initializiation". I am creating a DLL as a
"Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry
points as opposed to the normal DllMain entry point in unmanaged
code, but I have not manually added a DllMain, if that is what is
meant, other than following the instructions to convert to mixed
mode by adding __DllMainCRTStartup@12 to the Force Symbol
References property. Do any of the three situations apply to me,
or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.


The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call
my initialize and terminate static member functions at the
beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.

 

[Ronald Laeremans [MSFT]]

What specifically from std::string do you think is most critically needed?

As far as STL paradigm containers, we hope to have good news for the Whidbey
release.

Ronald Laeremans
Visual C++ team

There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after they
finished using your dll.

Then it will have to be an application doing this from its WinMain or main
routine. It's a PITA for people using MC++ mixed mode components to have to
do this, but there was no way I could create a pure mode component given the
C++ component code I am porting from a standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the System::String
class, which is not nearly as robust and easy to use as std::string. The
other weaknesses, most of which I can normally code around, is the
inferiority of the .NET containers to the standard C++ containers, and the
lack generic algorithms which deal with containers. But the System::String
class is the biggest sore point. I really wish MS would give up trying to
foist the weak string classes from VB and MFC on the programming world, look
at the great standard C++ string class, and attempt to create a string class
for .NET that is as good as std::string is. Why they continue to believe
their string class abortions are worthwhile is totally beyond me. It is the
height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of my
component to call my initialization routines for my MC++ component, I will
have to do it.

Albert

Albert Szilvasy wrote:
See below:
I received no answers about this the first time I posted, so I will
try again. My inability to decipher an MSDN topic may find others
who have the same inability and someone who can decipher and
explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL is
already set up with this option in the linker, and the previous
explanation about mixed mode says "you must modify your DLL to have
an explicit entry point". Is this first instruction correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to avoid
the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.


2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That Consume
the DLL for Manual Initializiation". I am creating a DLL as a
"Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed entry
points as opposed to the normal DllMain entry point in unmanaged
code, but I have not manually added a DllMain, if that is what is
meant, other than following the instructions to convert to mixed
mode by adding __DllMainCRTStartup@12 to the Force Symbol
References property. Do any of the three situations apply to me,
or can I just ignore the instructions in this section ?
[ALBERT:] #3 applies to you. Managed entry point in this context is
simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.


The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry points",
so I want to know if I have to implement the code mentioned in that
solution, and then have a console or Window program manually call
my initialize and terminate static member functions at the
beginning and end of their main and WinMain routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where does
it do this ? I would have guessed from a DllMain PROCESS_ATTACH and
PROCESS_DETACH but as I don't see any DllMain I am confused about
how one tracks startup and shutdown in an assembly dll.

 

[Edward Diener]

It isn't that different from components using COM though who also had
to init COM after DLL init and uninitialize before existing.

I assume you mean "unitinitialize before exiting".

The most obvious difference is that COM has to be initialized and
uninitialized by a single call for all COM objects. With mixed mode C++ .NET
assemblies, each mixed mode assembly has to be initialized and terminated.
That is a far more onerous situation.

Also there appears to be no entry or exit point in .NET assemblies for
initializing and terminating other assemblies which it is using, since
DllMain does not exist. If the facility is meant for only .NET EXEs to do in
the WinMain ( or main ) routine, this places an extra burden on the creator
of the EXE since some of the mixed mode assemblies with which this has to be
done may not even be used directly by the EXE. It would be much better for
mixed mode assemblies which reference othe mixed mode assemblies to do the
initializing and terminating of those other assemblies, but the lack of
clear entry and exit points preclude this.

Finally, of course, I am still reading that there is a chance for lockup for
mixed mode assemblies even after all the recommendations for initializing
and terminating mixed mode assembles have been made. Nor is there any
explanation of what could still be causing a lockup, nor of any workarounds
for that rare situation. So anyone writing a mixed mode MC++ assembly could
lock up an application using it, and the recourse to it is to tell the end
user that it is MS's fault as if that will excuse on'e own .NET components
or classes in some end users estination.

Ronald Laeremans
Visual C++ team

There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.

Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.

Albert
Albert Szilvasy wrote:
See below:
I received no answers about this the first time I posted, so I
will try again. My inability to decipher an MSDN topic may find
others who have the same inability and someone who can decipher
and explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL
is already set up with this option in the linker, and the
previous explanation about mixed mode says "you must modify your
DLL to have an explicit entry point". Is this first instruction
correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to
avoid the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.


2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That
Consume the DLL for Manual Initializiation". I am creating a DLL
as a "Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed
entry points as opposed to the normal DllMain entry point in
unmanaged code, but I have not manually added a DllMain, if that
is what is meant, other than following the instructions to
convert to mixed mode by adding __DllMainCRTStartup@12 to the
Force Symbol References property. Do any of the three situations
apply to me, or can I just ignore the instructions in this
section ?
[ALBERT:] #3 applies to you. Managed entry point in this context
is simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.


The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry
points", so I want to know if I have to implement the code
mentioned in that solution, and then have a console or Window
program manually call my initialize and terminate static member
functions at the beginning and end of their main and WinMain
routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to
above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where
does it do this ? I would have guessed from a DllMain
PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
am confused about how one tracks startup and shutdown in an
assembly dll.

 

[Edward Diener]

What specifically from std::string do you think is most critically
needed?

How about append, assign, compare, erase, find, find_first_not_of, find,
find_first_of, find_last_not_of, find, find_last_of, insert, rfind, and
replace; all in nearly any combination, with substrings and offsets which
one could imagine. I realize that System::String has some of this in more
limiting respect, but why not go with what is best and get it over with
instead of trying to maintain backward compatibility.

I know that System::String is immutable, but any of the aforementioned
functionality in std::string which would normally change the string itself,
could return a new System::String in .NET.

You really should have modeled your own System::String after the C++
std::string class, and its rich functionality, rather than the VB and MFC
functionality, which is much poorer and more limiting. It is too bad that MS
did not learn in this regard and settled for much less.

As far as STL paradigm containers, we hope to have good news for the
Whidbey release.

Ronald Laeremans
Visual C++ team

There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.

Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.

Albert
Albert Szilvasy wrote:
See below:
I received no answers about this the first time I posted, so I
will try again. My inability to decipher an MSDN topic may find
others who have the same inability and someone who can decipher
and explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL
is already set up with this option in the linker, and the
previous explanation about mixed mode says "you must modify your
DLL to have an explicit entry point". Is this first instruction
correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to
avoid the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.


2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That
Consume the DLL for Manual Initializiation". I am creating a DLL
as a "Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed
entry points as opposed to the normal DllMain entry point in
unmanaged code, but I have not manually added a DllMain, if that
is what is meant, other than following the instructions to
convert to mixed mode by adding __DllMainCRTStartup@12 to the
Force Symbol References property. Do any of the three situations
apply to me, or can I just ignore the instructions in this
section ?
[ALBERT:] #3 applies to you. Managed entry point in this context
is simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.


The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry
points", so I want to know if I have to implement the code
mentioned in that solution, and then have a console or Window
program manually call my initialize and terminate static member
functions at the beginning and end of their main and WinMain
routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to
above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where
does it do this ? I would have guessed from a DllMain
PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
am confused about how one tracks startup and shutdown in an
assembly dll.

 

[Steve Terepin]

Could one arrange to have the initialisation performed automatically, by
defining a static constructor for every managed class in the assembly, and
making that call the initialisation function (if it hadn't already been
called) ? That would absolve clients from explicitly calling that
initialisation function. Or am I being naive ?

Trouble is, even if that worked, there's no equivalent way to perform the
un-initialisation :-(

S.

It isn't that different from components using COM though who also had
to init COM after DLL init and uninitialize before existing.

I assume you mean "unitinitialize before exiting".

The most obvious difference is that COM has to be initialized and
uninitialized by a single call for all COM objects. With mixed mode C++ ..NET
assemblies, each mixed mode assembly has to be initialized and terminated.
That is a far more onerous situation.

Also there appears to be no entry or exit point in .NET assemblies for
initializing and terminating other assemblies which it is using, since
DllMain does not exist. If the facility is meant for only .NET EXEs to do in
the WinMain ( or main ) routine, this places an extra burden on the creator
of the EXE since some of the mixed mode assemblies with which this has to be
done may not even be used directly by the EXE. It would be much better for
mixed mode assemblies which reference othe mixed mode assemblies to do the
initializing and terminating of those other assemblies, but the lack of
clear entry and exit points preclude this.

Finally, of course, I am still reading that there is a chance for lockup for
mixed mode assemblies even after all the recommendations for initializing
and terminating mixed mode assembles have been made. Nor is there any
explanation of what could still be causing a lockup, nor of any workarounds
for that rare situation. So anyone writing a mixed mode MC++ assembly could
lock up an application using it, and the recourse to it is to tell the end
user that it is MS's fault as if that will excuse on'e own .NET components
or classes in some end users estination.

Ronald Laeremans
Visual C++ team

Albert Szilvasy wrote:
There's no such thing as assembly startup/shutdown. At least, this
contract is not standardized as it was with traditional dlls (i.e.
DllMain). I believe they looking at standardizing something similar
but it doesn't currently exist.

The client of your dll will have to call minitialize before they
start using any other functions in your dll and mterminate after
they finished using your dll.

Then it will have to be an application doing this from its WinMain
or main routine. It's a PITA for people using MC++ mixed mode
components to have to do this, but there was no way I could create a
pure mode component given the C++ component code I am porting from a
standard C++ environment.

The main weakness IMHO, of the pure mode NET C++ is the
System::String class, which is not nearly as robust and easy to use
as std::string. The other weaknesses, most of which I can normally
code around, is the inferiority of the .NET containers to the
standard C++ containers, and the lack generic algorithms which deal
with containers. But the System::String class is the biggest sore
point. I really wish MS would give up trying to foist the weak
string classes from VB and MFC on the programming world, look at the
great standard C++ string class, and attempt to create a string
class for .NET that is as good as std::string is. Why they continue
to believe their string class abortions are worthwhile is totally
beyond me. It is the height of arrogance to think so.

Thanks for your information. As much as it hurts to direct users of
my component to call my initialization routines for my MC++
component, I will have to do it.


Albert
Albert Szilvasy wrote:
See below:
I received no answers about this the first time I posted, so I
will try again. My inability to decipher an MSDN topic may find
others who have the same inability and someone who can decipher
and explain it.

I have some questions about the instructions for creating a mixed
mode DLL in the MSDN topic "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode" in the
"Managed Extensions for C++ Reference".

1) The first instruction in converting to mixed mode is to link
with /NOENTRY. This occurs despite the fact that a pure mode DLL
is already set up with this option in the linker, and the
previous explanation about mixed mode says "you must modify your
DLL to have an explicit entry point". Is this first instruction
correct ?
[ALBERT:] Yes, this is correct. You must link with /NOENTRY to
avoid the "loader lock" bug.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha

rt/html/vcconMixedDLLLoadingProblem.asp)
The explicit entry point referred to here is the one that you are
instructed to create further down in the article. (see below).

OK, I understand and it makes sense. What confused me was asking me
to make a change when there was no necessity to do so, because the
standard setup for a pure mode .NET class library already has the
/noentry flag set.


2) I don't understand the three areas to consider for making
further changes under the topic "Modifying Components That
Consume the DLL for Manual Initializiation". I am creating a DLL
as a "Class Library (.NET)" project. I have not added in any DLL
exports myself using __declspec(dllexport), and I expect the
end-user of my Dll will use it for the .NET components I have
created. I also don't have any idea what is meant by managed
entry points as opposed to the normal DllMain entry point in
unmanaged code, but I have not manually added a DllMain, if that
is what is meant, other than following the instructions to
convert to mixed mode by adding __DllMainCRTStartup@12 to the
Force Symbol References property. Do any of the three situations
apply to me, or can I just ignore the instructions in this
section ?
[ALBERT:] #3 applies to you. Managed entry point in this context
is simply static or
instance method of managed type.

Thanks, that clarifies what is meant by "managed entry points". One
usually thinks of DllMain for DLLs, and WinMain or main for GUI and
console apps, as entry points. Now I understand that the term for
"managed entry point" is any .NET types methods.


The last
possibility may apply,"Your DLL's consumers can use managed code,
and your DLL contains either DLL exports or managed entry
points", so I want to know if I have to implement the code
mentioned in that solution, and then have a console or Window
program manually call my initialize and terminate static member
functions at the beginning and end of their main and WinMain
routines.
[ALBERT:] I'm a bit confused here because you said that you only
have managed clients
and managed clients don't have WinMain that you could modify.

A managed client could be a .NET WinForms application, could it not
? I am creating .NET components, so I assume my clients are either
other .NET DLLs or .NET applications.

Nevertheless, the answer is yes.
Your clients will explictly have to call
ManagedWrapper.minitialize() on startup and
ManagedWrapper.mterminate()
shutdown. This is the explict entry point that is referred to
above.

If one of my .NET component assemblies uses another of my .NET
component assemblies, should I specifically call the latter's
ManagedWrapper.minitialize and ManagedWrapper.mterminate functions
from within my own ones ? What prevents these routines from being
called more than once as a pair, or does it not matter ?

Finally I noticed that my .NET component DLL has no DllMain, unlike
a .NET Windows Form application which does have a WinMain. Is there
a reason to have this with a mixed-mode DLL, or is it just
completely unnecessary in .NET assemblies ? If a pure mode assembly
needs to initialize my assembly by calling
ManagedWrapper.minitialize and ManagedWrapper.mterminate, where
does it do this ? I would have guessed from a DllMain
PROCESS_ATTACH and PROCESS_DETACH but as I don't see any DllMain I
am confused about how one tracks startup and shutdown in an
assembly dll.