VC++ 9.0 ATL/CRT merge modules error

[rdilipk]

We recently installed Visual Studio 2008. As a part of the deployment process I included the VC++ ATL 9.0 and the VC++ 9.0 CRT merge modules (along with their policy counterparts) in the Redistributables section of my InstallShield project. The IS build now throws the following error:

ISDEV : error -4075: File not found. An error occurred merging Module 'Microsoft_VC90_ATL_x86.CEC8F2E3_AC9A_357C_BFCB_BFAC37C4AC50:0' for Feature '*********'.
ISDEV : error -4075: File not found. An error occurred merging Module 'Microsoft_VC90_CRT_x86.0138F525_6C8A_333F_A105_14AE030B9A54:0' for Feature '*********'.
ISDEV : error -4075: File not found. An error occurred merging Module 'policy_9_0_Microsoft_VC90_ATL_x86.A50B7592_50BC_31A9_9E25_32121F451D37:0' for Feature '*********'.
ISDEV : error -4075: File not found. An error occurred merging Module 'policy_9_0_Microsoft_VC90_CRT_x86.52105B6B_A3EF_3A90_882A_947B287C203A:0' for Feature '*********'.

I really can't understand what is going on here. All the relevant files necessary to includes these merge modules, viz:

Microsoft_VC90_ATL_x86.msm
policy_9_0_Microsoft_VC90_ATL_x86.msm
Microsoft_VC90_CRT_x86.msm
policy_9_0_Microsoft_VC90_CRT_x86.msm

are expectedly found under: C:\program files\common files\merge modules

The command line build that we use to perform the build correctly passes that path as the -o parameter (in fact this was working perfectly fine when we were using Visual Studio 2005 and packaging the VC++ 8.0 versions of the same set of merge modules (CRT/ATL)).

So just for testing, I also include the same set of files but for the 8.0 version of VC++ merge modules and that works just fine. What is it about 9.0 that is causing this error?

[rdilipk]

I can't be the only person having this problem and I am fast running out of ideas. Any help will be highly appreciated.

[rdilipk]

While one person seems to have got it to work in this thread:
http://community.installshield.com/showpost.php?p=413343&postcount=11

The solution given does not make sense to me. The MSM files mentioned in my first post are found under: c:\program files\common files\merge modules and the command line parameter to ISSABld.exe mentions that full path in the -o parameter.

I am just not getting this...

[rdilipk]

Some kind soul had run into a similar problem last year here:
http://community.installshield.com/showpost.php?p=387716&postcount=1

Of course, his question never got answered. This is just nuts...

[esiemiat]

So you are able to build the install on your development machine but when you go to your SAB machine it throws the errors mentioned above? What is the command line you are using to build the project using the SAB?

[rdilipk]

Yes.. My development machine has the fullblown IDE and building from there works just fine. Now we have a cruise control system set up for nightly builds and such on a different machine. That machine has only the SAB version installed. I run that with the following command line:

ISSABld.exe -p "MyProjectFile.ism" -y 1.0.0.1 -c "SINGLE_EXE_IMAGE" -b "SomePath" -o "C:\Program Files\Common Files\Merge Modules"

and I know for sure the merge modules that are throwing this error are found under the Merge Modules directory.

What is even more irritating is, this same command line has no problem picking up the 8.0 versions of the VC++ CRT/ATL merge modules which are found in the exact same folder.

Which is why I wanted to know what is it about the VC++ 9.0 versions that is causing ISSABld.exe to barf?

[Sairen]

Did anyone ever find a solution to this? I'm running into exactly the same problem.

I've already tackled the issue where the path is too long to copy these modules, and shortened the names where I can. This only happens on the SAB machine, and the error doesn't say anything about anything being too long. The msm IS in one of the folders that being searched according to the -o parameter.

[dsockut]

I had the same problem.

It seems that the problem started after a VS 9 service pack upgrade on our build machine.

After the upgrade - c:\program files\common files\merge modules still contained the same file names - BUT - the VC 9 msm files were actually of a newer version, and their internal GUIDs had changed.

So as far as the installation project is concerned - the Merge Modules it is linked to - are no longer there.

To solve this problem, I had to update the c:\program files\common files\merge modules folder on my development machine with the new VC 9 merge modules (to reproduce the problem that the build fails) and then go to the Redistributables pane, select "Browse for Merge Module" - and reselect all the VC9 msm files - one by one. This will create duplications in the list of Merge Modules. So I had to remove the check boxes associating the old merge modules to my features - and then set the check boxes on the new lines - in order to associate my features to the new ones (which I just added to the list. But pay attention - they have the same names...).

Hope that makes sense to someone out there.

Cheers

[zmfcat1]

I ran across a similar issue. In my case there was an issue merging the merge modules during the time of the install build -- it was complaining about long path name. I changed the build path to be a shorter length and it resolved the problem for me. Hopefully thsi will be useful for someone.

Lesson I learn't: Always review the build log carefully!

[DLloyd]

So this is what happened to me...

By policy, the VM I was building from had automatic updates turned on. We had to bring down the VM (which had been running for over a year). When it came back, some updates were installed.

After getting the same "File not found" error for CRT/MFC using the Stand alone build, I noticed the date/time of the files had been updated in C:\program files\common\merge modules. I opened the files in Orca and, indeed, the GUI of the .msm had changed.

The fix is relatively simple:
1) Look in the "MsiAssembly" (or other tables) to get new .msm GUID
2) Open your .ism file in a text editor
3) Search the file to find your old GUID, then replace it with the new GUID

The stand alone build should now be able to "find" your merge module