MFC42.DLL in .NET Apps
-
The MFC in VC7 is version 7, that's why the EXE uses mfc70.dll. --Mike-- Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer My really out-of-date homepage Sonork-100.19012 Acid_Helm
Obviously. However, the .net framework (20MB) is certainly not small. I don't want to distribute this dll when mfc42.dll would be fine. Rick Eastes. ------------
-
Obviously. However, the .net framework (20MB) is certainly not small. I don't want to distribute this dll when mfc42.dll would be fine. Rick Eastes. ------------
You should just be able to distribute the MFC7 dlls. The .NET framework is only required for managed applications. Michael :-) Time flies like an arrow. Fruit flies like a banana
-
Obviously. However, the .net framework (20MB) is certainly not small. I don't want to distribute this dll when mfc42.dll would be fine. Rick Eastes. ------------
From VS.Net redist.txt file :
The following merge modules have been provided for use when
redistributing the Visual C++ runtime files. Redistributing
the merge modules is the recommended method for the
redistribution of these files.VC_atl70.msm
atl70.dll (UNICODE)
atl70.dll (ANSI)VC_CRT.msm
msvcr70.dllVC_CRT_IO.msm
msvci70.dllVC_MFC.msm
mfc70.dll
mfc70u.dllGDIPlus.msm
gdiplus.dllMFC_Loc_E.msm
mfc70deu.dll
mfc70esp.dll
mfc70fra.dll
mfc70ita.dllMFC_Loc_FE.msm
mfc70chs.dll
mfc70cht.dll
mfc70jpn.dll
mfc70kor.dllVC_STL.msm
mscvp70.dllWhat they are saying is that redistribuing DLLs is wrong and obstrusive to the new XP install procedure. You must distribute what they call Merge modules (.msm files). Btw, .mcm is a subformat of the general Windows Installer SDK (.msi database). Otherwise it won't install on XP, depending on the profile. Have fun.:~ And if you still want to distribute sharewares on a low deployment basis (for 9x for instance), just distribute these : mfc70.dll msvcr70.dll msvcp70.dll (stl) msvci70.dll I recommend to put these files in the app directory, not on system32.
And I swallow a small raisin.
-
From VS.Net redist.txt file :
The following merge modules have been provided for use when
redistributing the Visual C++ runtime files. Redistributing
the merge modules is the recommended method for the
redistribution of these files.VC_atl70.msm
atl70.dll (UNICODE)
atl70.dll (ANSI)VC_CRT.msm
msvcr70.dllVC_CRT_IO.msm
msvci70.dllVC_MFC.msm
mfc70.dll
mfc70u.dllGDIPlus.msm
gdiplus.dllMFC_Loc_E.msm
mfc70deu.dll
mfc70esp.dll
mfc70fra.dll
mfc70ita.dllMFC_Loc_FE.msm
mfc70chs.dll
mfc70cht.dll
mfc70jpn.dll
mfc70kor.dllVC_STL.msm
mscvp70.dllWhat they are saying is that redistribuing DLLs is wrong and obstrusive to the new XP install procedure. You must distribute what they call Merge modules (.msm files). Btw, .mcm is a subformat of the general Windows Installer SDK (.msi database). Otherwise it won't install on XP, depending on the profile. Have fun.:~ And if you still want to distribute sharewares on a low deployment basis (for 9x for instance), just distribute these : mfc70.dll msvcr70.dll msvcp70.dll (stl) msvci70.dll I recommend to put these files in the app directory, not on system32.
And I swallow a small raisin.
StephaneRodriguez wrote: I recommend to put these files in the app directory, not on system32. If you do this, it's better statically linking to MFC. This way, the installer size will be smaller, since only the needed code will go to the final .EXE Concussus surgo. When struck I rise.
-
StephaneRodriguez wrote: I recommend to put these files in the app directory, not on system32. If you do this, it's better statically linking to MFC. This way, the installer size will be smaller, since only the needed code will go to the final .EXE Concussus surgo. When struck I rise.
Well Daniel I believe you're right, at least in theory, But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation). In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
And I swallow a small raisin.
-
StephaneRodriguez wrote: I recommend to put these files in the app directory, not on system32. If you do this, it's better statically linking to MFC. This way, the installer size will be smaller, since only the needed code will go to the final .EXE Concussus surgo. When struck I rise.
My MFC application compiles successfully in both VC++7.0 and VC++6.0 but I feel I have wasted my time and money buying VC++7.0 WHY? I need to have a small distributable. Here are two senarios: 1. Compile with .NET Need MFC70.dll which most computers don't have. 2. Compile with VC6 Runs on ALL computers without ANY additional dll's :mad:Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL Rick Eastes. ------------ http://www.eastes.net
-
Well Daniel I believe you're right, at least in theory, But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation). In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
And I swallow a small raisin.
StephaneRodriguez wrote: But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation). I've never had a problem with statically linking. Perhaps you wrote some bad code? StephaneRodriguez wrote: In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall. Yikes! I still suspect that isn't true, but I greped the mfc dlls and mfc42.dll has DllRegisterServer in it. Thankfully none of the MFC70.dll's have that in there so maybe they've changed things. Joel Lucsy (jjlucsy@ameritech.net)
-
My MFC application compiles successfully in both VC++7.0 and VC++6.0 but I feel I have wasted my time and money buying VC++7.0 WHY? I need to have a small distributable. Here are two senarios: 1. Compile with .NET Need MFC70.dll which most computers don't have. 2. Compile with VC6 Runs on ALL computers without ANY additional dll's :mad:Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL Rick Eastes. ------------ http://www.eastes.net
Yes, somewhat waste of money especially if you don't have C# in the package you bought. What's more is that MFC70 has STL embedded everywhere, much harder to debug a callstack than the previous release IMHO. For some programmers however, MFC70 is a new step to achieve robustness and so on,
And I swallow a small raisin.
-
Well Daniel I believe you're right, at least in theory, But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation). In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
And I swallow a small raisin.
StephaneRodriguez wrote: In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall. This isn't true: 1. MFC dlls are not COM components. You can't regsvr32 mfc70.dll. (But you can create COM components with MFC). 2. COM components doesn't register themselves each time they are loaded. 3. With a COM DLL, it doesn't help installing the DLL on your app directory, because, when registered, it will be the only one DLL to be instantiated. Concussus surgo. When struck I rise.
-
My MFC application compiles successfully in both VC++7.0 and VC++6.0 but I feel I have wasted my time and money buying VC++7.0 WHY? I need to have a small distributable. Here are two senarios: 1. Compile with .NET Need MFC70.dll which most computers don't have. 2. Compile with VC6 Runs on ALL computers without ANY additional dll's :mad:Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL Rick Eastes. ------------ http://www.eastes.net
RickEastes wrote: Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL Have you tried changing the LIB and INCLUDE search paths ? This probably would help... Concussus surgo. When struck I rise.
-
StephaneRodriguez wrote: In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall. This isn't true: 1. MFC dlls are not COM components. You can't regsvr32 mfc70.dll. (But you can create COM components with MFC). 2. COM components doesn't register themselves each time they are loaded. 3. With a COM DLL, it doesn't help installing the DLL on your app directory, because, when registered, it will be the only one DLL to be instantiated. Concussus surgo. When struck I rise.
Daniel Turini wrote: MFC dlls are not COM components Fair enough for mfc7, I admit I didn't chcked the exports functions before posting an answer,
And I swallow a small raisin.