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.
Related
I have two installers:
Installer A installs A.dll v1.0.0.0
Installer B updates A.dll to v2.0.0.0
When I uninstall B, it does not delete A.dll. There is still A.dll with version 2.0.0.0
A.dll (v2.0.0.0) can be removed only from installer A.
Installers have different UpgradeCode and Component Ids.
How can I remove the replaced content of a Product from installer B?
Files that are shared between two setups (file is installed to the same absolute path by both setups) must maintain a single, stable component GUID to allow Windows Installer reference counting to work correctly. The mechanism to achieve this in Windows Installer is a merge module. WiX features its own way to handle shared files with the WiX include file approach.
I wrote an answer a while back with more information on merge modules and WiX include files here: WiX 3.8: Two MSI using the same registry values. How to delete registry values only if both MSI are uninstalled?
If you need to use different versions of the dll with different applications, then they should be installed to a private location for each application and they should have different component GUIDs:
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyExe.exe version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyDll.dll version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyExe.exe version 2.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
Alternatively you can install them to a shared location in separate folders and bind properly via your manifest:
CommonFilesFolder\MyCompanySharedFiles\1.0\MyExe.exe version 1.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp1\MyDll.dll version 1.0.0
CommonFilesFolder\MyCompanySharedFiles\2.0\MyExe.exe version 2.0.0
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
CommonFilesFolder\MyCompanySharedFiles\2.5\MyExe.exe version 2.5.8
ProgramFilesFolder\MyCompanyFolder\MyApp2\MyDll.dll version 2.0.0
You can deploy the shared files with a separate MSI so they can be updated without recompiling your main MSI, or you can use a merge module to compile the shared files into your main MSI (sort of static linking).
Finally you can install the shared files to the GAC if they are .NET assemblies (but don't):
When and when-not to install into the GAC?
What are the advantages and disadvantages of using the GAC?
Or you can install native Win32 files to the WinSxS side-by-side folder. For native files you can also install shared in System32 or SysWOW64 or another non-side-by-side, but shared folder.
A similar answer here: Wix Toolset: How to restore replaced file on uninstall. Much more elaborate than the above description.
And here is a rather comprehensive (and verbose unfortunately) description of how Windows Installer component referencing really works: How exactly are files removed during MSI uninstall?
And finally an answer with some recommendations on how to improve and simplify WiX files by using default attributes and enabling automatic component GUID generation. Highly recommended for you to check out: Continue the Wix setup after having a service that could not start. Don't let the title confuse you, it is generic WiX advice. I particularly recommend looking at the automatic component GUID feature since it will help you do component GUID assignment correctly.
I have the same problem as described here:
https://github.com/NLua/NLua/issues/33
Though I have followed the instructions to create a console application...
http://www.screencast.com/t/M12TqePQxW
...which works just fine, when I create a library project and reference it from another project (in this case, a Web API project) the following error occurs:
Unable to load DLL 'lua52': The specified module could not be found.
At this line:
using (var lua = new Lua())
How can a library project be made with the NLua nuget package without failing?
It is the exact same issue as described in the GitHub issue, the Nuget package is missing two DLLs that you need to use lua52.dll. One small difference, the current package (version 1.3.2.1) includes a newer version of lua52.dll that was built with VS2013. And therefore has a dependency on msvcr120.dll and msvp120.dll.
Beware that this may change in the future when Nuget updates your project.
As-is, you need to download and install the Visual C++ redistributable package for VS2013. Run both vcredist_x64.exe and vcredist_x86.exe so your project can run either in 32-bit or 64-bit mode.
To avoid having to do this on the machine on which you want to deploy your program, I recommend you copy the two DLLs from the c:\windows\system32 (64-bit) or c:\windows\syswow64 (32-bit) directories into the same directory as your EXE.
The package author could have done a better job putting this package together. Short from including the DLLs in the package, the better solution would be for him to rebuild lua52.dll with the /MT option so these dependencies are linked in. Consider clicking the New Issue button to let him know.
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'd like to create an installer package to install registration-free COM components (with manifest files included). This would be more or less a self-extracting archive to place some files in a target directory given as commandline argument, but it would also need to check or install some other redistributables like VC++ or DirectX.
The package is supposed to be used in another applications's installer as some kind of redistributable package itself. It should not be registered in the "Program and Features" dialog of Windows but has to be removed with the application. Ideally there should be no changes to the Windows registry.
So far I haven't been very successful. Can anyone please provide me with some hints regarding this use case?
You've got about a dozen different questions in that one question. Start with just creating a simple MSI that successfully installs your files and your manifest. Create a COM client to test it. You can also put AppSearch and LaunchConditions in your MSI to detect your dependencies and not allow installation if they are missing.
That's about all you should have to do for this simple question. As for the other questions.... if you are a redistributable and someone else is silently installing you then it's their job to handle the installation of the other redistributables. Also if they don't want you listed in Programs and Features they can pass the ARPSYSTEMCOMPONENT=1 to your installer and you won't be listed. If they want to uninstall you when they uninstall themselves, that's their problem not yours.
If you are really creating a redistributable to be used by other products, sometimes a merge module is the appropriate solution. They build their MSI files and include your merge module.
Otherwise, reg-free COM is in theory an easy install because you're just installing manifest files and Dlls etc. However I don't understand how that could be used by other apps because (IIRC) a client app exe needs your manifest and Dll in their install folder, so how can they do that when they are not installed yet? Or even if they are installed how can you find them? So that goes back to the merge module idea so they include your merge module and install an exe, your manifest and your Dll in the same location. When they uninstall so do your files.
I've had some trouble getting WiX projects to build on build servers. One of the pain points has been that my WiX projects are referencing libraries in c:\program files... and the build process calls executables in the same path. This is a bummer because I have to install WiX toolkit in order to get my project to build.
What's the best way to eliminate this headache by having all build tools local to the project being built?
Is there a nuget package that does this? (At the time of writing it appears not, but I wanted to verify.) Package Restore capability would be nice because then I don't have to include the (many) WiX files in git.
If not, what do I need to download from WiX? What do I need to modify so that the compiler knows where to find the binaries to build WiX projects?
You can download just the WiX Binaries .zip from http://wixtoolset.org/releases/ then you can modify your wixproj file and update the <WixToolPath></WixToolPath> element to point to your WixBinaries
The WiX documentation has an article that explains how: Integrating Wix Projects into your Daily Builds
There is an unofficial nuget package at WiX.Toolset.
However, note that this seems to only be applicable to the setup project itself (i.e. it cannot be used to fetch wix binaries for e.g. a class library assembly).