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
Related
Currently I'm distributing a software product that includes three merge modules:
Microsoft_VC80_CRT_x86.msm
ATL.msm
policy_8_0_Microsoft_VC80_ATL_x86.msm
Some customers use packaging technology that doesn't like these MSM files (I think because they have technical problems with them writing to WinSxS). Can I just distribute the dll files directly into my application's Program Files folder, and if so which dlls do I need? Is it just atl80.dll?
Your alternative is to run the VC_redist.exe for that version of Visual Studio, run it from the bootstrapper with whatever setup tool you're using.
I don't know what you mean about packaging technology. The only way merge modules (msm files) can be installed is to add them at build time to an MSI file build. In other words, the only packaging technology that's relevant is Windows Installer and MSI files. So you need to find out exactly what this issue is. Everyone uses the merge modules or the VC_redist.exe because it's the only reliable thing to do.
One issue with doing it yourself in an unofficial way is that Windows Update can't find them (and that applies to static linking to). So when Microsoft applies a security fix to those Dlls then you are leaving your customers vulnerable.
My problem is the following:
I have multiple applications that I want pack in one installer so when the user runs it, they will be installed automatically instead of installing or copying each single application.
I have a program that's already a setup file (.exe) and two .exe files which can be executed manually and do not need an installation. So what I want is:
Build an installer so when the user opens it - the .exe file of the setup program gets installed and the other applications which dont need to be installed will be copied somewhere in a path.
Whats the best solution?
I think you need a packaging programs to create an installation package, such as:
AdvancedInstaller
InstallShield
InstallAnyware
The first two of them have a freeware version. Maybe you can see if the required features are available in the freeware version.
I would suggest Advanced Installer (allows easy chaining of installs) if you have no significant deployment experience. Otherwise I would suggest Wix and its "Burn" feature (ability to chain installers in sequence). Please read the following answers for context:
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
Windows Installer and the creation of WiX
Wix to Install multiple Applications
Read this if you want to get going with Wix quickly
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'm trying to put together an installer package that will install VS2010, SQL Server 2008 R2, and some other development tools into a single executable installer. The idea is to create something similar to XAMPP's installer that installs Apache, PHP, Perl, and MySQL in one convenient installer.
The installers for almost every program are .msi files. Are there any applications that can 'package' all the installers into a single executable? Barring that, what other solutions are there out there to perform something like this? I've looked into using a batch file with the /passive switch for each .msi so it does an unattended install, but I'd like to make it look like a GUI application if at all possible.
Many commercial setup authoring tools offer more or less support for this. You basically create an EXE or MSI installer which acts as a wrapper for existing third-party packages.
Usually these packages are added as prerequisites, but they can also be executed through custom actions.
You can find a list of setup tools here:
http://en.wikipedia.org/wiki/List_of_installation_software
Another solution is to create your own EXE wrapper which shows custom UI and handles the third-party packages.
I'm using a VS 2008 Setup and Deployment project to deploy a mixed managed / unmanaged application. I've had trouble registering mixed-mode DLL's using the built-in registration property ("vsdraCOM" enumerated value of the "Register" property.) As a workaround, I've added a .NET custom install assembly (with a class that derives from System.Configuration.Install.Installer.) I'm certain that that class is running and a number of operations successfully install and uninstall through code in that assembly, including executing the Dll(Un)RegisterServer entry point of a number of assemblies.
However, one DLL is not successfully registering. It is the only DLL that depends on some 3rd-party redistributable assemblies that want to be installed to the GAC. I have those assemblies installed to the GAC thanks to the built-in support for that in VS 2008's setup and deployment projects, and I know that is working. I've confirmed that what is happening is that the custom action is executing before the installer executes the GAC installation.
Whew. So my question is, is there a way to force the installer to execute the GAC installation before executing the custom action? Is there a way to use the "Condition" property of the custom action to do this? If not, what's my best alternative? Capturing the registry entries from the DLL and adding them to the registry settings for the installer (don't like this because someone may add new COM servers to the class in the future)? Using .NET code to install the assembly into the GAC manually (don't know how to do that yet)?
Thanks,
Dave
The setup projects you can create in Visual Studio are very limited. It only allows custom actions to be scheduled at 4 points. However, MSI allows custom actions to be scheduled at any point in the process with some restrictions on what they can do.
My first solution is to stop using Visual Studio 2008 as your setup development tool. The Visual Studio team has tried to abstract away all the complexity of creating an install. However, in the process they have also taken away all the flexibility of MSI. Wix, InstallShield, or Wise are much better products for anything but simple installs. I started off using Visual Studio for our installs and it ended up being too much work. There was always one more workaround to be implemented and its side effects to be dealt with.
If you can't switch technology, then you will need to learn how to manually modify the resulting MSI file. In your case you will need to modify the InstallExecuteSequence table, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. You can do this manually through Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx or through the MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Make sure to download Orca and run the validation scripts against your install. The scripts point out numerous problems that fixing will save you countless hours when deploying to customer machines.