I have created an msi installer using the WiX setup project, and I also have a Bootstrapper project where I have all the other pre requisites for the installation of the msi installer. Instead of having two separate projects- one for creating an msi installer and one for bundling all the dependencies together- can I combine all of this in just a single project?
I have two codes currently- bundle.wxs for the bootstrapper, and product.wxs for the installer. I am hopingto have just one wxs file with all the code.
WiX isn't designed to support that. One wxs builds the MSI and then the other builds the EXE that knows and possibly embeds the MSI. Two different layers of the solution.
It's something I've considered adding to WiX but it is not implemented. It is not high priority so there is also no schedule for it to be implemented.
Related
I am using Installshield 2015 with Visual Studio 2013. I created a setup.exe for my application. In order to start my application, user needs to run SpeechPlatformRuntime_x86.msi or SpeechPlatformRuntime_x64.msi.
How can I add these msi file into my project so after installation finishes, it automatically run msi file?
These sound like they provide dependencies. Since you deliver a .exe file, I would suggest creating a prerequisite and including it in your project. This will result in them being installed first, and your main .msi (or InstallScript) project contents will follow.
(If you delivered only a .msi file, you would probably have to document your dependency. You could look into the Chained .MSI Packages support, but it's not really that well suited for handling dependencies.)
I have a .MSI installer project created in vs2010. This .MSI includes many *.msm (merge module file). Is there a way to select specific *.msm based on different windows platform(ex: xp, win7, vista..)during installation?
For instance, if the target platform to install this .MSI is winXP, my .MSI will know what .msm to choose instead of choosing all .msm during installation.
BTW, is there a way for .MSI to access a specific *.dll which resides in .msm ? Again, for instance, if the .MSI project includes a .msm and this .msm includes many *.dll, is there a way to select a specific *.dll in .msm during installing this .MSI ?
my main purpose is to have my .MSI knowing what .dll/.msm to use under different windows platform during installing my .MSI.
What you basically need is to assign each merge module to a new feature and set install conditions on that feature. I don't think this is possible with VS 2010 however, but there are some commercial setup authoring tools that can do it.
Merge modules (.msm) are similar in structure to a simplified Windows Installer file (.msi). A merge module cannot be installed alone, it must be merged into a .msi file. The best alternative is to obtain a freely distributed merge tool or purchase one of the merging tools available from independent software vendors. You can then use the functionality provided by Mergemod.dll.
The intended use of merge modules was to provide a standard method for developers to deliver shared Windows Installer components and setup logic to their applications. Merging is therefore something typically done by the author of the installation package prior to deployment. Trying to determine and perform the correct merge when the application is being installed does not seem like the best approach.
You could instead create a separate .msi for each target platform. Merge the appropriate .dll into each package. Then include logic in your setup application to check the user’s system and then install the correct package.
As was suggested by the previous answer, you could merge all the .dlls into a single installation package which you have authored such that the installation of certain features and components are conditional upon Operating System Property Values .
You can consider Using Transitive Components in your package. The typical use for transitive components is to prepare a product to reinstall during a system upgrade. The author of the installation package specifies those components that need to be swapped out during a system upgrade as having the transitive attribute. When the user later upgrades the system, the product must be reinstalled. Upon this reinstall, the installer removes the earlier components and installs the later components, without having to install the entire product. This might serve your scenario well if you expect your users to upgrade their systems.
I have a fresh WIX UI Install project in VS which compiles down into an MSI. Everything is working great with it.
It installs/uninstalls the files I want successfully. For example, it drops 3 DLLs into a Program Files folder, installs a Windows Service, and GAC's a DLL.
Now let's say I install on this in a given environment. Then one of our DLLs change and we need to upgrade this install without affecting other files already installed (such as the service) So my thought would be I would need a patch/upgrade MSI that would target that one DLL and just overwrite that particular file.
What is the simplest way to accomplish this? Do I need VS projects essentially for each patch/update MSI? Below is my current 2 WIX related projects (installer + custom action)
For updating just the DLL a patch is recommended. Visual Studio doesn't support patches, but you can try using WiX: http://wix.sourceforge.net/manual-wix2/patch_building.htm
Please note that patches have some restrictions: http://msdn.microsoft.com/en-us/library/aa367850(VS.85).aspx
A MSI which overwrites just one file is a bad mistake because you are not using the Windows Installer update mechanism.
If you want a MSI, it will have to be a major upgrade. A major upgrade will automatically uninstall the old version before installing the current one.
Greetings!
I have a solution in VS2010 that defines 3-4 individual applications.
These 3-4 apps are individual (but related) components that I need to have individually installed on our production servers during deployment. I toyed with using WIX mondo to generate a multi-feature WIX installer, but found that it would be more beneficial to allow that these applications be able to be installed individually as well as via a single-source for all of them, preferably configurable to choose which to install during an installation.
I noticed that there is a WIX project type called "Bootstrapper Project" but I cannot find much documentation around it on the web, and do not know if it is a project type that will actually assist me in creating a deployment installation bootstrapper for my projects. (i.e. a setup.exe file that will install, one after the other, each project as either defined in the installer, or optionally selectable via the installer as it runs)...
what is the best method to do this within WIX, using pre-existing WIX installers for individual programs?
In Wix, the support to create a bootstrapper is through a tool called "Burn". Burn has been pushed out to v4.0 (or version 3.6). So that isn't much help.
You can use an open source tool like dotNetInstaller: http://dotnetinstaller.codeplex.com/
Here is an overview on how to create a setup installer that checks for the .NET Framework (which in and of itself is not very useful, but shows you how to work with dotNetInstaller):
http://www.lostechies.com/blogs/gabrielschenker/archive/2010/05/19/creating-a-bootstrapper-with-dotnetinstaller.aspx
Or you can follow the instructions here: http://msdn.microsoft.com/en-us/library/ms165429(v=VS.100).aspx
And use the Bootstrapper Manifest Generator here (although there appear to be 64-bit issues): http://code.msdn.microsoft.com/bmg
Say I have a component which is made up of a bunch of DLLs. And the component was released using a .msi installer for several versions.
Now, we need it to be a .msm so that it can be included in other msi installers. So we need to build a merge module that can upgrade from .msi installations.
How to do that? Or it cannot be done?
We are using Wix.
As long as you maintain the same GUIDs and set the components to be shared then it should be possible to move the components into a MSM instead. The MSM will just cause the components to be included into the installers it is included in the same as if the components had been added to the installer so it's more like just copying the components into several installers.
Granted I haven't tried out any of this, only had to the reverse of fixing a mistake when multiple installers shared GUIDs for components when i did not want that behavior.