I've had the pleasure of not having to work with InstallShield very much, so I appreciate the answer to this is will be extremely simple, or more than likely, there is not much I can do about it (unless I compile my own MSM package?), but with the MSM Merge Modules, I have selected to use Visual C++ 9.0 MFC (x86) WinSXS MSM, version only states as 9.0, but getting a "SideBySide" error to say the version for 9.0.21022.8 is not found when the end user is trying to run the product.
With having 4 different flavours of version 9 in my C:\Windows\winsxs folder, I presume its not using the desired one of the version above, but there is no way to validate this in the properties of what is selected in InstallShield.
How can I either specify the selected MSM module is to use the set version of the files that is within the 9.0.21022.8 folder, or where can I find a MSM I can download to install over the top in InstallShield?
Thanks.
I suppose those 4 merge modules would be :
ATL,
CRT,
MFC,
MFCLOC,
OpenMP.
May be the sxs error can be corrected if you install the x86 merge mods for a 32 bit installation
and install both x86 and x64 merge mods for a 64 bit installation.
Related
Can I integrate installation of Microsoft Visual C ++ 2010 redistributable together with my installation package through the Wix Toolset?
I tried this with a custom action, but it does not install if another installation is in progress. Would someone have any suggestions on how to do this?
Also, another question: can I call an MSI installer within this MSI installer that I am creating?
You can't do recursive MSI installs - at the risk of stating the obvious, when you get that error "another install is in progress" that other install is you.
If you use merge modules to install VC Runtimes AND you have a C++ service that is dependent on them that you start with StartServices (WiX ServiceControl) then you may find that the service won't start. This is because the SxS versions of the C++ Runtimes are not available until InstallFinalize, which is after the StartServices action. Possible solutions to this are:
Have the service built with static links to the C++ runtimes, but then updates to the VC++ runtime Dlls won't be applied to your built binary, in case that's an issue.
Use a bootstrapper like Burn to run the VC++ redist exe before you install your own MSI file.
Copy the runtime Dlls to your app folder as private copies that will be used only by your app. This kind of thing, old but still applicable I believe:
http://blogs.msdn.com/b/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx
Another issue you may run into with using the merge modules is that they require a per machine install. If you include them in a per User install then the install will fail.
You can install the C++ runtime files using the C++ runtime merge module:
How To: Install the Visual C++ Redistributable with your installer
And to your second question: No - this is not possible.
I'm writing merge modules for a project I'm working on.
I build two merge modules, one for 32-bit and one for 64-bit. I want to include them in a WiX installer but it tells me I can't:
error LGHT0345: 'installer\bin\x64\Release\en-us\myproject.msm' is a 64-bit merge module but the product consuming it is 32-bit. 32-bit products can consume only 32-bit merge modules.
Is there a way to make a dual CPU project so I can include both?
WiX version is 3.6.
Windows Installer doesn't support multi-platform packages. If you need to write to the 64-bit portion of the file system or registry, you need a 64-bit package.
When my file set includes DLLs with one ore more dependencies to the C++ run-time DLLs I need to install the file from VCRedist.exe. This can be difficult, since each DLL is dependent on a specific version of the C++ run-time.
How do I add automatically the run-time redistributables to my installer?
How do I handle DLLs that require different versions of the C++ run-time in the WinSxS?
You need to install the latest version (highest) version required by your libraries and a policy file that redirects older versions to the new version.
You can do both with merge modules installed with Visual Studio. They're usually located in C:\Program Files\Common Files\Merge Modules. See MergeRef element and an example how to install Visual C++ redistributable with your installer. You will also need to add a policy merge module to your install.
You can simple make sure the latest vcredist is installed, it automatically includes support for older versions.
I think the easiest it to use bootstrapper to install the runtime before your installer runs. You might need to create your own package, but it is easy to use Bootstrapper Manifest Generator for this.
In the product.xml you can add an installation check to make sure it is not installed twice, for example:
<InstallChecks>
<MsiProductCheck Property="VCRedistInstalled" Product="{1F1C2DFC-2D24-3E06-BCB8-725134ADF989}"/>
</InstallChecks>
See here for other GUIDs.
Neither heat nor Votive does support the requested feature. The run-time DLLs must be added manually.
Is it possible to install both WiX 3.0 and 3.5? If I install 3.5 after installing 3.0, it removes the 3.0 files - and if I attempt to install 3.0 after 3.5, it tells me there is a newer version already installed.
I'm in the process of migrating from VS 2008 to VS 2010, so one version (branch) of my application is is using VS 2008 (existing production version), and another one is in VS 2010 (future version). WiX 3.5 is required for VS2010.
What this means is on my build server, at the moment, I cannot build both the current version and the new version, as one will report an error about not finding WiX files:
c:\buildAgent\work\fe55ddb47cebe4fd\MyApp.wixproj(25, 11): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I'd prefer not to upgrade the current version of my product to WiX 3.5 as 3.5 is still in beta, and as is I had to cherry pick a weekly build to get it to work at all (I'm just hoping by the time my next version is ready, that WiX 3.5 will be stable).
Is there a way to install both side-by-side? Do I just need to copy the 3.0 files into the Msbuild directory?
I ended up:
Installing WiX 3.5.1916 with the .MSI package (later versions failed in strange ways which I didn't put much effort into figuring out)
Copying the following files to the build server:
%programfiles%\Windows Installer XML v3**
HKLM\SOFTWARE\Microsoft\Windows Installer XML\3.0
(SOFTWARE\Wow6432Node\ for x64 systems)
%programfiles%\MSBuild\Microsoft\WiX\v3.0**
It builds successfully now, I haven't done much testing with the resulting files though. So it seems it is possible to have 3.0 and 3.5 concurrently, it's just a minor pain to make it work.
The way wix is currently designed you can't have 3.0 and 3.5 both installed on the same machine. They do provide a zip version of wix that enables you to let your build automation self deploy wix onto the build server to get around this limitation. You do lose certain things like visual studio integration though.
I have a .NET application that runs on both x86 and x64. I'd like to have a 32 bit WiX installer that will work on both platforms but I'd like it to install to /Program Files/ rather than /Program Files (x86)/ on 64 bit operating systems.
How do you go about doing this?
Update:
My idea was to assign the ProgramFilesFolder or ProgramFiles64Folder value to my own property, depending on whether it was a 64 bit environment or not, and then use that property value on the directory.
I have very little experience with WiX so if this idea is even possible I have no idea. If it is what would you test on to see if it is an x64 environment? Also how would you then assign a property value from ProgramFilesFolder or ProgramFiles64Folder depending on the earlier 64 bit environment test.
Any help is appreciated!
MSI doesn't support 32-bit packages installing to 64-bit directories.
While it's true that MSI's support here is weak, you might want to read the following article and comments then decide for yourself how you want to proceed.
http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html
I just found this, I tried your exact idea and no dice. You can't actually access ProgramFiles64Folder unless you are running a 64-bit installer.
I've given up and am just installing my 64-bit component to ProgramFilesFolder. It's not that nice aesthetically but it works :)
I was able to install a x32 package with WiX into the \program files folder usig the idea from http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html which is to:
1 - use ProgramFiles64Folder for the directory
2 - change the setup project's settings to add a compiler switch. Its on the 'Tool Settings' tab and you add '-arch x64' to the compiler settings.