05-06-2011 04:05 PM - edited 05-06-2011 04:09 PM
Hello all,
I recently upgraded one of my .NET applications from MS 2009 to MS 2010. Now that I am using MS 2010, my installer (InstallShield LE with Visual Studio 2010) will not compile. Specifically, I get the following errors:
Error 1 -4072: Error retrieving dependency Microsoft_VC100_CRT_x86.DF495DFD_79F6_34DF_BB1E_E58DB5BDCF2C:0 of c:\program files (x86)\common files\merge modules\MStudioCommon.2010.msm ISEXP : error : -4072: Error retrieving dependency Microsoft_VC100_CRT_x86.DF495DFD_79F6_34DF_BB1E_E58DB5BDCF2C:0 of c:\program files (x86)\common files\merge modules\MStudioCommon.2010.msm. Error 2 -4072: Error retrieving dependency Microsoft_VC100_ATL_x86.DF495DFD_79F6_34DF_BB1E_E58DB5BDCF2C:0 of c:\program files (x86)\common files\merge modules\MStudioUI.2010.msm ISEXP : error : -4072: Error retrieving dependency Microsoft_VC100_ATL_x86.DF495DFD_79F6_34DF_BB1E_E58DB5BDCF2C:0 of c:\program files (x86)\common files\merge modules\MStudioUI.2010.msm
Solved! Go to Solution.
05-09-2011 01:53 PM - edited 05-09-2011 01:54 PM
Hi Steven,
I was wondering if you have tried out the steps outlined here to try to solve the problem.
05-10-2011 08:32 AM - edited 05-10-2011 08:34 AM
Yes, I have followed all the steps outlined in the link you posted. All of the dependencies for the required merge modules are present on my computer (and selected for the installation). I can even see the Microsoft_VC100_ATL_x86.msm and Microsoft_VC100_CRT_x86.msm merge modules listed in the "redistributables" list. But even when I select those merge modules, it still gives me the "error retrieving dependency" message.
The next step in that link you provided was to "contact the company that authored the merge module."
I just tried duplicating this problem with a new VS 2010 solution. Here were my steps:
1) Create Windows Forms .NET 3.5 solution
2) Add a Waveform Graph to Form1
3) Add an InstallShield LE Project to solution
4) Add the output of the Windows Form's project to the installer
5) Build the Windows Form project, then build the InstallShield Installer project
Here is the output:
05-11-2011 02:38 PM
Hello Steven -
I'm going to guess that you've recently installed Service Pack 1 for Visual Studio 2010. It appears that SP1 for VS 2010 overwrites the two merge modules you mentioned, and replaces them with merge modules with different signatures. Because the Measurement Studio 2010 merge modules were built against the non SP1 version of Visual Studio 2010, the build errors you're seeing result.
I've attached the non SP1 version of these merge modules below. You should be able to add them to your installer project and get past the build errors. Please let me know if you have any trouble or questions.
NickB
National Instruments
05-12-2011 08:24 AM
I copied the new merge modules and now everything is working.
Thanks!
02-08-2012 02:14 AM
Hello Nick and Steven,
I am having the same problem as Steven described (VS 2101 with SP1) however I am using the Visual Studio Installer rather than InstallShieldLE.
I have downloaded the msm from Nicks post and unzipped the file in an arbitrary folder
I then include the .msms in the Setup as described & rebuilt
but the error remains.
Do the .msm files need to be paced in a specific location?
Did I misunderstand something?
Thanks and Regards
Ivan Vernot
02-08-2012 09:22 AM
If you want the Visual Studio setup wizard to automatically pull in those merge modules, you will need place them in the <ProgramFilesDir>\Common Files\Merge Modules directory. Otherwise you will need to manually reference those merge modules from your setup project.
Hope this helps.
02-08-2012 04:13 PM
Hi Jonathan
That worked.
What are the implication to other (future) projects of using 'old' .msms files instead of the 'fresh' ones from Microsoft?
Are NI planning to release new mstudio merge modules for VS2010 SP1?
Thanks and Regards
Ivan
02-10-2012 09:49 AM
Hi Ivan,
Very good question. Allow me to provide you with a little background first and then I will answer your exact questions.
When we build a binary that depends on a specific version of the VC runtime, we make sure to install the associated VC runtime merge modules. This allows us to support merge module deployment in Visual Studio. For example, suppose we built a binary that had a dependency on the 64-bit VC2010 CRT runtime. This would imply the following:
The problem is that Microsoft sometimes changes their module signature during Visual Studio updates and service packs. When the signature changes, it breaks our dependency chain. Ideally, Microsoft should keep their signature the same for the each version of Visual Studio. Another option by Microsoft would be to provide a better way to safely share their runtime merge modules across different installers. When this dependency chain breaks, the Visual Studio auto-detection of merge modules and their associated dependencies breaks. Thus, you only end up with the NI merge modules in your setup project.
Answers to your questions:
What are the implication to other (future) projects of using 'old' .msms files instead of the 'fresh' ones from Microsoft?
If you are building binaries in Visual Studio 2010 SP1 that link against the VC runtime, then you will need to make sure and distribute th SP1 merge modules. Otherwise, you could end up with a VC runtime issue on the target system (e.g., you are building against a higher version of the 2010 VC runtime than what gets installed on the target system). Its probably safer if you include the SP1 merge modules from Microsoft rather than the original 2010 merge modules. The only implication here is that you will need to manually add them to your project instead of the auto-detection.
Are NI planning to release new mstudio merge modules for VS2010 SP1?
If any of our binaries start building against VS2010 SP1, then yes, we will include the VC 2010 SP1 merge modules.
As a side note, we are fully aware of the issue and are looking into better solutions to handling this issue.
08-30-2012 04:25 AM - edited 08-30-2012 04:27 AM
@nickb wrote:
Hello Steven -
I'm going to guess that you've recently installed Service Pack 1 for Visual Studio 2010. It appears that SP1 for VS 2010 overwrites the two merge modules you mentioned, and replaces them with merge modules with different signatures. Because the Measurement Studio 2010 merge modules were built against the non SP1 version of Visual Studio 2010, the build errors you're seeing result.
I've attached the non SP1 version of these merge modules below. You should be able to add them to your installer project and get past the build errors. Please let me know if you have any trouble or questions.
NickB
National Instruments
Hi Nick,
Would it be possible to attach the non SP1 x64-bit versions?
Regards,
Sergey