Mh ..., this might cause some unexpected problems:
When I use the /CLR switch for my MFC-DLL, msvcmrt.lib (msvcm80.dll) is used
.. Now this lib is not used for all other DLLs and EXEs that have not been
compiled with /CLR (regardless of wether they are linked with MFC as shared
or static).
Now since in this case different versions (copies) of the CRT Library are
used as well, I will not be able to pass pointer to a CRT-Object between a
DLL, that is compiled with /CLR (and with MFC linked as shared) and a DLL
that is compiled without /CLR (and with MFC linked as shared).
This would kind of suck, since I would not be able to implement a wrapper
that wraps some .NET (i.e. WinForms) controls to be used in a plain
unmanaged MFC-EXE.
"Jochen Kalmbach [MVP]" <no********************@holzma.de> schrieb im
Newsbeitrag news:%2****************@TK2MSFTNGP11.phx.gbl...
Hi bonk!
So the reason, why I can't pass MFC Types across DLL boundaries if MFC is
linked differently has nothing to do with MFC itself but with the fact
that different copies of the CRT libraries are be used. Is that correct?
Yes.
Are there different copies of the MFC libraries used as well ?
Yes.
If linking MFC statically WOULDN'T require a special version of the CRT
that is different from the one used when lnking as shared library, I
would be fine. (yes, thats highly hypothetical).
The MFC depends on the CRT. And you need to select the correct CRT version
(DLL or static) if you want to use the DLL/static MFC...
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/