View Full Version : Merge Module Destination

10-27-2003, 09:46 AM
This is the case

I have an installation kit containing a set of Assemblies and a set of merge modules containing MFC71 related stuff. I tell the Install Shield to put the Merge Module files in the Default Destination!

The Files is placed in C:\Program Files\Microsoft Visual Studio .NET 2003 !! Not good! My assemblies cant find them here!

I tell Install Shield to put the Merge Module Files in the System folder! Same result! The files is placed in the .NET 2003 folder !!!! My assemblies still cant find them!

How do I specify in install shield that it should put the files somewhere where my assemblies can find them ????

10-27-2003, 01:03 PM
The MFC 7.1 merge modules are designed (by microsoft) to install files to INSTALLDIR (TARGETDIR in script projects). These modules can NOT be redirected even using Microsoft's Visual Studio Installer.

10-28-2003, 01:42 AM
You say two different things; 1. You cant redirect the mfc71 and 2. only by using TARGETDIR??? So can you or cant you do it???

Why cant Install Shield use this to tell where the Merge Module should be installed???

I can set TARGETDIR to what ever and MFC71 IS installed here! I just have to do it in a Cusom Action...

10-28-2003, 10:56 AM
These merge modules are authored so they can NOT be re-directed like any other merge modules.

Are you using a Basic Msi project or an InstallScript project? If you are using a Basic Msi project the files in the MFC 7.1 merge module should install to INSTALLDIR by default. This behavior cannot be changed. This is how microsoft authored this merge module. It is authored so that the MFC files get installed in INSTALLDIR.

10-29-2003, 01:47 AM
Dont you call it redirecting when you set the TARGETDIR?????

If I could catch an event that is raised before installation of the Merge Modules I would claim that I could redirect each of the MFC71 merge modules to all different destinations!!

That was what I would expect the Install SHield to do for me!

10-29-2003, 10:49 AM
I think we're just going in circles here. To resolve this please answer the following questions.

1. Are you using a Basic Msi project, InstallScript Msi project or an InstallScript project?
2. If using a Basic Msi project or InstallScript Msi project, what have you set INSTALLDIR to?
3. If you are using an InstallScript project, what is your main install location set to?

Suppose the answer to questios 2 or 3 are C:\Program Files\Test. If so, does the MFC 7.1 files get installed in C:\Program Files\Test? If they do then there is NO problem here. That's how it is supposed to work. If you disagree with this behavior please contact microsoft for information.

If the MFC 7.1 files are NOT installed here then there is a problem that we need to look in to.

10-30-2003, 01:41 AM
I am just trying Dev 9 as an evaluation! It seems to work like you describe! Dont you guys control when the Merge Modules are installed???? If you do it should be easy to use the settings the user sets Through the 'Redistributables' tab to set the INSTALLDIR before the different merge module is installed or is there something I have misunderstood???

I skipped Dev 9 because It doesnt fixed my problem 100 % and went back to Dev 8 and here the Merge Module only gets installed correctly if I use a Custom Action that sets the TARGETDIR!!

10-30-2003, 11:01 AM
The reason it won't work on Dev 8 without a custom action is because this is a bug in Dev 8. We fixed this bug in Dev 9 so you don't have to create a custom action for it anymore.

Dont you guys control when the Merge Modules are installed????
Yes we do. But for re-direction to work there is a Windows Installer standard that the merge module has to meet. That is the responsibility of the merge module author. In this case that would be microsoft. They do NOT want this module to be re-directable. So they create the module in such a way that it's simply not possible.

So once again this merge module CAN NOT BE REDIRECTED. It is not meant to be redirected. It is created such that the files are installed to main application directory. Microsoft created these merge modules like this so that you can have side-by-side installs and avoid DLL hell. The results are the same if you consume these merge modules using Visual Studio Installer.

11-13-2003, 06:51 AM
We have had the same issue. However we have been in touch with Microsoft Developer Support for Windows Installer/.NET Deployment and they have supplied us with fixed merge modules which allow you to retarget the destination directory correctly. That was back in July 2003. I'm surprised that Installshield are not shipping these updated files with v9.

Maybe Microsoft haven't made them available for general release.

11-13-2003, 10:44 AM
We have had the same issue. However we have been in touch with Microsoft Developer Support for Windows Installer/.NET Deployment and they have supplied us with fixed merge modules which allow you to retarget the destination directory correctly. That was back in July 2003. I'm surprised that Installshield are not shipping these updated files with v9.
I wasn't aware of this. I have searched the microsoft website a few times but have never found these modules to be publicly available. Could you send me one of the modules that microsoft sent you? I would like to take a look at it and then contact microsoft to see if we can get our hands on thse newer modules. They don't always publicly release some stuff. You can email me at chandimar@installshield.com. Thanks!!

02-06-2004, 10:50 AM
I converted my IPS7.1 project to DS9 SR1, so it is an IScript project (not MSI). I added the MFC 7.1 Merge Objects to an existing FEATURE that previously installed MFC InstallShield Object.

I am having the same problem, even when I set the Destination in the Merge Modules Properties to WINSYSDIR the files get dumped in the root of the application folder. The applications can't find this location as they are further down in the tree.

As to the prior comments I understand that the Merge Module comes from MS but they do provide a way to select a different Destination folder. I set it and it does not work properly. If there are newer versions availble how do I locate them?

I have had a open Silver SR on this and the related Error 5000 issue for some time. I will also be posting these comments through that channel. But if anyone can tell me how to resolve this issue I would appreciate the assistance.

02-06-2004, 11:26 AM
I would contact Chandima - InstallShield Developer listed in this post directly. I've uploaded to him the updated but as yet unreleased Merge modules which fix this issue, by now he should have found out if he can distribute them to Installshield users.

Mark Oppedahl
02-17-2004, 03:22 PM
We, too, are having the problem. Since earlier versions of MFC installed to the winsys directory I figured mfc 7 should, too, but it seems impossible to put it there. Chandima says side-by-side considerations warrant installation in the application directory: fine, except our executables reside in a subdirectory to the targetdirectory (targetdir\bin) and the mfc files sitting in targetdir don't get the job done.

So -- could I either get the updated merge modules, or where can I in script (mine is an installscript project) temporarily change targetdir to point to our bin directory so the merge modules go there? I'm not familiar enough with how the merge module holder object works to know where to properly manipulate the targetdir setting.

Thanks -- Mark Oppedahl, CarteGraph Systems

02-17-2004, 03:52 PM
Mr Chandima did not want to send me the Microsoft's 'pre-release' Merge Modules that nLawrence mentioned. My contact at IS Support that I was also working with said that the IS engineers advised that I download their MFC Runtime Object Template and change the files and logic to support MFC 7.1 rather than 6.2. I could not get the download from the web site to work so they put it in MySupport for me to download. I completed modifing the object this morning but I branded it with my companie's name to make it clear that it was modified from what IS provided. So I don't think I should distribute it but you could do the same thing. I can provide more detailed advice on this point if needed.

Prior to getting the Object template I had also planed to create a child object and under a parent object and try to change the value of TARGETDIR prior to calling the child object. Seems like that should work but I did not have a chance to try that approach.

Also I did not get anyware trying to point out that it looks like the problem is in the IS Holder object. I can't prove that point but the fact that when you look at what Microsot's own Setups do they put the MFC files in WINSYSDIR. Microsoft renamed all of the 7.1 files so there is no chance of tromping on earler versions of MFC. Microsoft's documentation implies that they should be installed to WINSYSDIR or to a COMMONFILES sub-folder. So the notion that the MFC files should be installed in each applications load folder is only comming from IS Support AND you cannot achieve that goal with the Merge Modules as distributed. It still sounds like a bug in DS9 to me, that might be agasperated by a problem in the MS modules, but I can't prove that opinion.

02-17-2004, 04:10 PM
So the notion that the MFC files should be installed in each applications load folder is only comming from IS Support
This is the way microsoft created these modules. The best proof of this is to launch Visual Studio Installer (this comes with Visual Studio - it's microsoft's own setup authoring tool) add any of the MFC 7.1 merge modules, build and run the setup. It will install the files in the location you choose to install your application.

The Windows Installer stuff behind it is as follows:
In the Component table of the merge module, the "Directory" column for each component is set directly to TARGETDIR. For a merge module to be retargetable, the value in this column should be defined in the directory table as a subfolder of TARGETDIR. This is NOT the case. By making this value TARGETDIR the module forces this file to get installed in whichever location that the end user chooses to install your application. DevStudio mimics this behavior making this module behave the way it is supposed to.

02-17-2004, 05:01 PM
I readily admit that I am not up to speed on creating Windows Installer projects as I just recently converted from using ISP7 to DS9. As soon as I have a chance I will look at it from the perspective you suggested. However the MFC 7.1 Merge Module that are distributed with DS9 has a Design Time dialog that allows a developer to specifiy a destination folder. The value that the developer sets for the Destination is ignored. This is not a good design in by any standard, which is why I question the explanation that it is intended behavior (among other observations).

02-17-2004, 05:09 PM
I totally agree with you on that. The dialog that launches in DevStudio should not show that the module is redirectable. You get the same sort of behavior even if you are using a Basic MSI project.

That's because you can't distinguish these modules from any other generic merge module. So DevStudio treats them as generic merge modules and shows the redirection property (which a property common to any generic merge module). However the redirection won't work because microsoft wrote these modules so that they cannot be redirected.

Mark Oppedahl
02-18-2004, 11:46 AM
OK, I still need to get the MFC7 dlls installed from my installscript project. Either they need to go in winsysdir or in my targetdir/bin folder. How do I accomplish that? If it's impossible with the merge modules I assume I can just manually install the various mfc7 dlls wherever I want using version checking, since I don't think there's weird interdependency stuff going on (like with MDAC for example). My staff is waiting for an install to test -- which should I try:

- Some sort of workaround to get the merge modules to work (temporarily reset targetdir somewhere to winsysdir or the bin subdirectory?), or
- Manually install mfc7 files?

02-18-2004, 12:33 PM
I went the "manually install the MFC files" route. I am still testing the results but so far they are positive.

Unlike MFC42.dll and MFC42u.dll the MFC71.dll and MFC71u.dll should not be self-registered. Also unlike MFC42 localization it appears all of the various localized MFC DLLs can be installed simultainiously to the same folder.

I elected to revert to installing these files to WINSYSDIR simply because that is what it appears MS is doing when they install there applications, like VS.NET. I also briefly experimented with putting the files at <TARGETDIR>\App-x-of-nFolder\, or <CommonFiles>\MyCompany\Shared and either of those options also work.

Mark Oppedahl
02-18-2004, 12:51 PM
Thanks. I'll probably try manual, and install to winsysdir since the Visual Studio .NET 2003 install puts them there (seemingly violating the supposed reason for the merge modules not allowing redirection). Thoughts Chandima? Any advantage to using the merge modules? I don't need localized mfc, just c and c++ runtime, mfc, and maybe atl. The files are

msvcp71.dll (c++ runtime)
msvcr71.dll (c runtime)
mfc71.dll (mfc)
mfc71u.dll (mfc)
maybe atl71.dll (two versions?)

Our install is targetting NT4 and above (2000, xp, etc) and Win98. Any special OS considerations with unicode/non-unicode dlls (it looks like the two atl files might be for 98 vs non-98 for example)? Other potential pitfalls?

This shouldn't be so hard! Putting executables in a subdirectory to the main installation directory isn't non-standard -- Microsoft does it with MS Office, Installshield does it with DevStudio 9.

02-18-2004, 12:52 PM
The easiset solution is to simply update the merge modules.
1. Open the msm in ORCA or Direct Edit mode in Developer/DevStudio.
2. Go to the Component table.
3. Change the "Destination" column values from TARGETDIR to SystemFolder.
4. Save and close the msm.
This will ALWAYS install these files to the system folder.

Disclaimer: These modules are authored by microsoft and altering them as mentioned above will make them not behave the way microsoft intended them to. This information is provided as is and is to be taken as a tip/trick/workaround provided by one Windows Installer user to another. This is NOT Installshield's official solution to the problem.

Mark Oppedahl
02-18-2004, 12:59 PM
Thanks ;).


02-24-2004, 09:44 AM
I have managed to invent a work-around for this problem. I needed to install ATL71, MFC71, MSVCP71, MSVCR71 dlls in a \bin subdirectory of TARGETDIR.

The functionality of the Merge Module "Destination" property can be mimicked through the use of InstallScript logic:

1) Place the Merge Modules into their own Feature group.
2) Create and attach OnInstalling, OnUnInstalling, OnInstalled, and OnUnInstalled event handlers for this Feature (see code).
3) In the OnInstalling and OnUnInstalling event handlers retain a copy of the current TARGETDIR and set the new TARGETDIR.
4) In the OnInstalled and OnUnInstalled event handlers reinstate the original TARGETDIR value.

Code: ======================================

STRING strOrigTARGETDIR; // Copy of original TARGETDIR during Prerequisites feature install

// The UnInstalling event is sent just before the feature
// Prerequisites is uninstalled.

export prototype Prerequisites_UnInstalling();
function Prerequisites_UnInstalling()
// Temporarily adjust TARGETDIR to Programs subdir for
// uninstallation of Microsoft Merge Modules
// The Installing event is sent just before the feature
// Prerequisites is installed.

export prototype Prerequisites_Installing();
function Prerequisites_Installing()
// Temporarily adjust TARGETDIR to Programs subdir for
// installation of Microsoft Merge Modules
// The Installing event is sent after the feature Prerequisites
// is installed.

export prototype Prerequisites_Installed();
function Prerequisites_Installed()
// Restore correct TARGETDIR
// The UnInstalling event is sent after the feature Prerequisites
// is uninstalled.

export prototype Prerequisites_UnInstalled();
function Prerequisites_UnInstalled()
// Restore correct TARGETDIR


Now the dlls get installed and uninstalled to my <TARGETDIR>\bin directory!

Hope this helps.

02-24-2004, 09:57 AM
Thanks for the info. I like that approach better than the other suggestions. I suspected an approach like that would be possible but did not take the time to prove the concept.

Mark Oppedahl
02-24-2004, 10:05 AM
I've already got Chandima's suggestion working, but the disadvantage is it requires changes to the merge modules, so next time they get updated my changes will be blown away. Plus if we ever change our build machine we'll have to remember to copy over the modified merge modules. The ultimate solution would seem to be Microsoft fixing what's pretty obviously a bug.


04-06-2004, 08:49 AM
I was solved a same problem. I recompiled these modules and it works for me fine just now.

go to

If somebody does a same job, please
publish also your result.

I know that this is not official solution of InstallShield, but an official solution
"corrective msm" totally broke my installation and it corrupts mdac25.

04-13-2004, 08:20 PM
I've got a rather strange problem while using mfc7.1, atl7.1 merge modules in my installation....the file are always copied to e:\. irrespective of where i have my setup files (i tried copying disk1 to c:\ but still the files were copied to e:\.)...i tried modifying paths in merge module's properties / feature's destination folder...I added feature install events to set TARGETDIR to desired folder..nothing worked..I'm not supposed to change msm files....Can someone help me...this is very critical as i'm already far behind my deadlines to complete installation...:eek: :eek:

04-14-2004, 08:17 AM
I'm sorry, but at the moment the only fix is to alter the msm's. If you are not allowed to edit the msm files, then you should build your setup uncompressed and edit the msi file manually. You just have to edit entries in the Component table, and it won't take you more than 10 minutes.

Once again, this is a bug in a microsoft merge module and NOT an InstallShield merge module. Microsoft authored these modules so that they are retargetable.

08-02-2004, 05:56 AM
I'm sorry, but at the moment the only fix is to alter the msm's.

Is this still the case?

I would not mind if it did copy the files to the Instalation directory, but I get them dumped in the root of C: :mad:

08-02-2004, 09:15 AM
See the Developer 8 thread "MFC71.dll Default Directory". Search for the string "SetMFC71" in the Developer 8 forum. By following the information in this thread about using the "SetMFC71" custom action I was able to solve my problem in Developer 8 and I carried the solution forward to DevStudio 9 with no problems.

08-02-2004, 09:21 AM
Thanks, I'll look into that.