MFC dependencies madness! | The Coffeehouse

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

I wrote a MFC application using MFC+MSXML 6.0 that relies on other libraries I wrote still using MFC but unfortunately now I found that in order to get it running on Windows older than Vista I need to install a lot of stuff.

On 95/98 it won't run because Windows Installer 3.0 (needed by MSXML 6.0 setup) can't be installed

On 2000/ME I need to install:
1) IE 6.0
2) SP4
3) Windows Installer 2.0 (and then 3.0)
4) MSXML 6.0
5) VC++ 2005 runtime

On XP:
1) SP2
2) Windows Installer 3.0
3) MSXML 6.0
4) VC++ 2005 runtime

any idea of how can I get out of this mess?

I can't include Windows Installer/Service Pack Setups/MSXML Setups because there are too much of them (they're localized).

I also don't want to directly put the MSXML/MFC libraries in the system32 folder manually (I want to use the official setups that install side-by-side libraries).

does somebody here knows any easy way to have my installer to automatically detect/download/install the stuff that the application needs in order to work? merge modules... anything?

andy_hanger18

You just wouldn't do that if you were writing an application for other end users. You'd specify the environment that your product would need to be able to run.

Also, statically link MFC when you compile your application.

Another suggestion. Consider one of the other free libraries / classes out there. If you are only doing very simple XML writing & parsing then hand-crank your own. Doesn't take long to do a very basic XML class.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

andy_hanger18 wrote:

You just wouldn't do that if you were writing an application for other end users. You'd specify the environment that your product would need to be able to run.

the environment needed is too complicated. VCRT and MSMXL have a lot of dependencies and I can't ask the users to install all that stuff.

andy_hanger18 wrote:

Also, statically link MFC when you compile your application.

I can't, because my application has a lot of DLLs all MFC-based (MFC DLLs can only access MFC in a shared way).

andy_hanger18 wrote:

Another suggestion. Consider one of the other free libraries / classes out there. If you are only doing very simple XML writing & parsing then hand-crank your own. Doesn't take long to do a very basic XML class.

At that point I could simply copy msxml3.dll in the application directory and register it.

damn if only MS released merge modules for MSMXL 6 all of my problems would be solved Sad

Sven Groot
My name has 9 letters. Coincidence? I think not...

I would set the service packs and IE version as a baseline requirement. Warn your users if they don't have it and tell them to use Windows Update to get it. Don't try to install those yourself.

With the VC redist I suggest you get rid of the redist and simply include the files from C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT in your installer. Have them installed in your application directory (not in the system directory!!!) and it'll work fine. You can probably exclude the msvcm80.dll file (which is only needed for managed C++ applications), but you must include the manifest file.

MFC can be handled the same way: C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.MFC. Again, install in your application directory, not the system directory!

That leaves on MSXML6. Unfortunately you will have to run the MSI file for this. You can use something like the Bootstrapper Manifest Generator to create a package for the VS2005 bootstrapper (or Google around, someone may already have created one). You place your new package in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages, and then you can use MSBuild to generate a bootstrapper that'll automatically detect and install MSXML6 and then launch your setup. You would have to include the files with your application or provide your own download server.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

I think then that I'm going to move all the needed DLLs in the application dir and screw the MFC/MSXML executables.

The DLLs by theirselves don't require anything else (they work perfectly on clean Windows 98 and Windows 2000 installs without any service pack or anything else installed) it's just that Microsoft put those lame dependancies that make it really hard to install them the "correct way".

Too bad none of those DLLs can be linked statically or I would've solved the problem immediately Sad

Thanks for the hints!

Sven Groot
My name has 9 letters. Coincidence? I think not...

How do you plan to do that with MSXML6? If you don't install it properly, you'll still have to register it. That means all applications using MSXML6 will use the version in your application directory. When your application is removed, unregistering the DLL will break every other application that uses MSXML. And if it's installed that way, your users won't be able to install any service packs for MSXML (that's also the reason no merge module is provided; it would make it impossible to update MSXML centrally, it's the same reason why no merge modules for .Net exist).

Either install MSXML properly, or don't use it. MSXML6 is only supported Windows 2000 SP3 as a minimum anyway, so if you want to support older Windows versions, you shouldn't use it. MSXML3 might be a good alternative, since it's the only other supported version of MSXML and everybody who has IE6 has MSXML3.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

Sven Groot wrote:
How do you plan to do that with MSXML6? If you don't install it properly, you'll still have to register it. That means all applications using MSXML6 will use the version in your application directory. When your application is removed, unregistering the DLL will break every other application that uses MSXML. And if it's installed that way, your users won't be able to install any service packs for MSXML (that's also the reason no merge module is provided; it would make it impossible to update MSXML centrally, it's the same reason why no merge modules for .Net exist).

Either install MSXML properly, or don't use it. MSXML6 is only supported Windows 2000 SP3 as a minimum anyway, so if you want to support older Windows versions, you shouldn't use it. MSXML3 might be a good alternative, since it's the only other supported version of MSXML and everybody who has IE6 has MSXML3.

actually I was planning on detecting the existance of MFC and MSXML6 before installing to avoid installing them if they're not neded.

if some other applications will install their own MSXML6 package (with the redistributable or not) then the new MSXML6's registration would replace the one my installer made so all the applications would automatically rely on the new one.

also MSXML once replaced won't be unregistered anymore by my uninstaller because the registration's registry would have been changed.

about the MSMXL service packs I could save msxml6.dll (if not present) in the system32 directory so windows update will still be able to detect it.

Sven Groot
My name has 9 letters. Coincidence? I think not...

YearOfTheLinuxDesktop wrote:
about the MSMXL service packs I could save msxml6.dll (if not present) in the system32 directory so windows update will still be able to detect it.

No it won't, because WU (as well as any MSP files) will be looking for the MSI installation registry, not the DLL.

Other installations might look for the CLSID value in the registry and falsely conclude they don't need to install MSXML6.

In any case, when your application is uninstalled, what would you do? If you unregister the DLL, it'll remove MSXML's registry information, including any information entered by a proper installation done later. If you don't unregister and no other installations of MSXML6 exist, you leave COM registration behind that isn't applicable.

Whatever you do, it's going to be a terribly fragile solution, unsupported and an all-round horrible idea.

Either install MSXML6 properly or use something else. There are no other options, imnsho.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

Sven Groot wrote:

YearOfTheLinuxDesktop wrote:about the MSMXL service packs I could save msxml6.dll (if not present) in the system32 directory so windows update will still be able to detect it.

No it won't, because WU (as well as any MSP files) will be looking for the MSI installation registry, not the DLL.

I've built unattended XP CDs in the past and I remember MSXML was being detected even without a proper installation. as long as I know Windows Update checks the DLLs/Executables versions of system files (in fact if a patched DLL/EXE becomes corrupted and Windows restores an old version from the Install Cd windows update will tell you to reinstall patches again).

Sven Groot wrote:

Other installations might look for the CLSID value in the registry and falsely conclude they don't need to install MSXML6.

where would the problem be? I could leave MSXML6.dll and MSXML6r.dll behind. All the installer does is copying those DLLs to the system32 folder and registering both.

Sven Groot wrote:

In any case, when your application is uninstalled, what would you do? If you unregister the DLL, it'll remove MSXML's registry information, including any information entered by a proper installation done later. If you don't unregister and no other installations of MSXML6 exist, you leave COM registration behind that isn't applicable.

the uninstaller I use checks if the COM registration is the same it made. if the DLL or the com registration has been altered everything would be left intact.

Sven Groot wrote:

Whatever you do, it's going to be a terribly fragile solution, unsupported and an all-round horrible idea.

Either install MSXML6 properly or use something else. There are no other options, imnsho.

as long as I could see that's the proper way to install MSXML because the installer does nothing interesting beside copying the DLLs and registering them (it doesn't even need side-by-side DLL installation).

MSXML6 installer doesn't even include a .CAT file like previous versions (!)

AndyC

Please, please, please don't do that. Just bootstrap the MSI file, the way you are supposed to do.

Every time you think you've outsmarted the official route, a sysadmin goes postal. Don't take that risk.

JKelley
Is it sad that my badge picture is one of the best ones I have of myself?

What are you using to author your setup program? InstallShield used to be pretty easy to setup those kind of dependencies and include the proper merge modules and whatnot.

I haven't tried Wise in awhile to see if it's any good, but I'd seriously look at one of those two if you can and aren't using one already.

If you ARE using them, have you tried creating different release images for the different targets? One for 95/98, and one for XP on up?

You're probably stuck requiring the users to upgrade to SP2 and IE on their own, but I bet the rest should be sorted out pretty easily.

anonymuos

Does this version of MSXML 6 work with Windows 98? (http://rapidshare.com/files/206551439/MSXML6.msi.html)

blowdart
Peek-a-boo

In reply to anonymuos

#Mar 7th @ 11:26 AM

Why on earth would you download an MS system component setup from a 3rd party site?!

zacharysyoung

In reply to blowdart

#Mar 7th @ 12:53 PM

Hi all,

I'm in the same boat as Sven Groot. I've gone through the trouble of authoring a custom package for MSBuild and bootstrapping--and it works perfectly!--but I don't how to get my resources (setup.exe, the MSXML 6 package, and my own installer) into one EXE. Does anyone have any recommendations for getting one unified setup EXE?