I have an app that on first installer run needs a boostrapper where you can choose the language of the installed app, install .net framework if it's not there yet and some other prerequisites.
I've taken a look at the WiX How To: Install the .NET Framework Using a Bootstrapper
but I don't see how to use this for other custom prerequisites.
What's the best bootstrapper to use for this?
After the app is installed we have an update check on the app startup. if a new version exists we need to download it and upgrade the software.
This wouldn't be a silent upgrade because the EULA and some other stuff might change in the meantime so we still need a GUI for those checks in the updater msi. So i'm considering different options on how to do this.
My first thought was to have 2 separate installers.
The first one would be with the bootstrapper and full GUI, the other would be with minimal GUI for updates.
Is there a better option?
I'd also like the access to the update installer on the to be limited to only users that have the software actually installed.
i'm not quite sure of the best way to do this.
I'm familiar with the WiX upgrade process itself with the upgrade code etc... so that's not the issue.
I'm just looking for a way to design all this in the best way possible.
Any ideas are appreciated. I'm using WiX 3.0.5419.0 from Visual Studio 2008.
I've taken a look at the WiX How To:
Install the .NET Framework Using a
Bootstrapper but I don't see how to
use this for other custom
prerequisites.
You can use the same technique (i.e. the msbuild GenerateBootStrapper task) to install custom prerequisites, but you'll have to author your own bootstrapper packages.
One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
As for auto-updating your application: it's not supported by wix. I believe there were once plans to add this functionality under the name clickthrough, but I don't think those plans ever matured. If they did, I can't find any documentation about it.
Related
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
I have an application which I have built in Visual Studio 2012, one part of which is in C# and one part of which is in C++. The GUI for the application uses a third party GUI control.
Consequently I have three dependencies that need to be checked for and installed with my project:
The Microsoft Visual C++ redistributable
The .NET framework 4.5
The GUI control
My installer for the project is currently built using WiX. Is there a way to make WiX do the following?:
At install time check for the presence of (e.g.) the C++ redistributable and install it if it is not present
Remove these components at uninstall (if and only if they were installed at install time, obviously)
If not, my guess would be that the answer is to create another C# project which can run each msi in turn, but I'd like to be able to do the whole thing through WiX - is it possible? If so, how?
WiX has added to its original purpose of being a Windows Installer toolset. It now has a bootstrapper/chainer/bundler/reboot manager/package manager, sometimes called Burn. In Visual Studio, it is accessible via the WiX Bootstrapper project template.
You'd need to have a WiX Setup project for your application. Then define a chain sequence for the four setups. VC and .NET should be marked permanent because you don't known if and when they should be uninstalled. Same thing probably goes for the GUI control. That leaves your application, which the bootstrapper will uninstall when it is uninstalled.
You could create a bootstrapper to install your application and its prerequisites.
WiX toolset provides all necessary tools for you to create a bundle that contains different packages, one of it would be your own MSI.
Have a look at Burn and the WiX toolset documentation. The How To Guides show ways to achieve exactly what you want, for example there is a tutorial describing how to Install the .NET Framework using a bootstrapper.
Maybe the Standard Bootstrapper Application is what you are looking for. Or have a look at customized Managed Bootstrapper Applications. For example the fancy Visual Studio 2012 installer is a WiX MBA. But be warned, in my opinion a MBA is a lot of work.
I'm trying to learn how to write MSI installer. I'm using WiX, and I'm curious. My application comes with the dependencies to the followign MFC and CRT libraries:
mfc90u.dll
msvcr90.dll
How do you install those?
There are some choices listed here. I recommend using the appropriate redistributables instead of installing individual DLLs.
With WiX 3.6 and later, you can create a chainer that runs multiple installers. You can create a VS project for that with a WiX Bootstrapper template.
Distibuting the vcredist dlls as private DLLs creates security risks for the user, and is discouraged, however if you distribute the version mentioned it must live in a subfolder of the app folder with a name specified in msdn docs. It is far better to use the vcredist exe (even if your app does not need all of the vc redist files),or the related msm. The location of the msm or private dlls is part of your VS installation and detailed in the VS redistribution license. The vcredist exe is available from microsoft's site. There are many different versions of the vs 2008 redist. Open your binary in a text editor and search for manifest to read the embedded manifest which details which version of the vcredist you need to deploy. Never take anything from the SXS folder. Regarding wix you can add the msm to your msi but there are issues with doing that. The prefered method is create a Wix bundle using the vcredist exe.
Our product currently installs via 4-5 MSI's which are created from .vdproj files which consist are created from the output from vs 2010 projects and additional information in merge modules.
I have been looking at InstallShield and WIX as a possible replacement due to VS2012 no longer supporting VS Setup Projects (oh no!) so we have to find something else.
I've had a little play with InstallShield and I couldn't really get to grips with it, additional to installing the product, the installer also has to take in a few parameters such as a database name and location etc. I couldn't seem to find a way to get this info into the InstallShield project - This was using InstallSHield limited edition for visual studio though
I'm not sure which would be the best to use? Has anybody had experiences with converting to WIX or IS from a VDPROJ?
EDIT
It looks like WIX is going to be the easiest and I am trying to get to grips with it.
I cant seem to find any useful posts that allow me to direct project output into my WIX installer, and how to create variables. (Without using plugins)
It's hard to give a simple answer because you are actually asking really high level questions that require an understanding of your installation needs and a whole bunch of training in the art of creating installers.
Personally I have installers that are 100% WiX, 100% InstallShield ( Both Limited Edition and Premiere Edition ) and a blend of the two.
Limited Edition is limited but it also does some things really well and provides some features that aren't really there and/or easy to implment in WiX.
One good strategy is to use InstallShield LE as a simple container and then do most of your authoring in WiX. I describe that pattern here in my blog:
Augmenting InstallShield using Windows Installer XML - Certificates
InstallShield Professional and above has a tool for migrating VDPROJ projects but I'd use it with caution. Most VDPROJ installers have some horrible authoring and it would be better to refactor rather then migrate.
I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX.
Also see the CodePlex home page: http://wixsharp.codeplex.com/
For developers primarily coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and directly integrates into the Visual Studio environment. I've been using it with great success in Visual Studio 2012 and 2013.
For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.
Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.
Wix# handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.
Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.
using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;
class Script
{
static public void Main(string[] args)
{
var project = new Project("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File(#"Files\Bin\MyApp.exe"),
new File(#"Files\Bin\TailorMyConfig.exe")),
new ManagedAction("UpdateConfigFile"));
project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
}
}
public class MyCustomAction
{
[CustomAction]
public static ActionResult UpdateConfigFile(Session session)
{
if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?",
"Config Tailoring Utility",
MessageBoxButtons.YesNo))
{
Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
}
return ActionResult.Success;
}
}
Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".
Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.
For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.
You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here:
How to modify .NET config files during installation?
Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.
The first accepted answer advocated this approach:
One good strategy is to use InstallShield LE as a simple container and
then do most of your authoring in WiX. I describe that pattern here in
my blog:
http://blog.iswix.com/2011/01/augmenting-installshield-using-windows_19.html
While that is a fine and workable approach, the approach I'm suggesting here has the following advantages:
ADVANTAGES OF USING Wix# PLUS WiX APPROACH
No need whatsoever to deal with InstallShield LE or any other proprietary installer product
The entirety of most installers are written in C# code, a familiar skill set
No need to learn the full WiX toolset environment up-front; you can start with C# code and then add the advanced WiX capabilities as you need them, using XML Injection.
The approach would work well in Continuous Integration environments, with all the components lending themselves to being XCopy-deploy installed on build servers, and all components being eminently suitable for automation by scripting, e.g., Powershell scripts.
If Microsoft changes course AGAIN on installer tools bundled with Visual Studio, you will NOT be impacted.
ELEMENTS IN COMMON WITH IS LE + WIX
Built on top of WiX Toolset capabilities, thus all capabilities of WiX XML can be incorporated into an installer
Many excellent "how-to's" for WiX solutions to deployment problems are available on SO and elsewhere
Generates authentic MSI Windows Installers, complete with uninstall capabilities and all the great features of that technology.
You will want to learn more about WiX and Windows Installer technology when creating installers. Advanced capabilities will often require dropping down into WiX XML.
Both are integrated more or less seamlessly into the Visual Studio environment. (If anything, the Wix# approach would have a slight advantage)
So, while the other approach is a workable solution, I recommend Wix# + WiX Toolset as the path of least aggravation, going forward, for VS2012, VS2013, VS201x. Perhaps the biggest advantage is that you are unlikely to ever have to have to change your underlying deployment technology and approach again, to be blindsided by Microsoft again, no matter what no matter what backroom deals Microsoft's marketing managers make to include or pull deployment technology from Visual Studio.
For a free tool WiX is your best choice. If you also are interested in commercial tools, Advanced Installer can help you create/convert the project much faster, without any scripting required. It also has a predefined project template for importing your VDPROJ. For what you need an Enterprise license is required, as you need access to its Dialogs Editor and SQL Scripts features. But you can test all of them in the trial period.
If you want to move to other installation system - NSIS or Inno Setup try this Visual Studio extension: http://visualstudiogallery.msdn.microsoft.com/5e57fe9a-ae5d-4740-a1c3-7a8e278e105b
I am quite new to Windows Installers, i faced some problems, but finally accomplished what i wanted. One important question remains for me. I can't figure out where i can download or how to create or update bootstrapper packages.
My application needed SQL server compact 3.5 and the bootstrapper package was installed on my hard disk by VS2008. What i wanted was SQL server compact 3.5 SP2 and i also needed an offline installation. I searched a lot on the internet, but could net figure out how to upgrade my SQLCE bootstrapper package to SP2, moreover i could not figure out where to download, create or upgrade these bootstrapper packages like e.g. .Net Framework myself.
I do know how to use Bootstrapper Manifest Generator in case i need to create a bootstrapper package, but to use BMG to create Microsoft packages i think i a short on information (i could not find too musch about this as well) to create correct package and product XMLs.
Maybe i am just silly, but if someone could explain me in what way i can update or upgrade my offline bootstrapper packages in ht Microsoft SDK folder, i will be grateful. It will save me a lot of misery next time.
Thanks a lot in advance!
Svatja
P.S. I obtained the SQLCE SP2 package by downloading and installing VS2010 express on my Vista test PC.
As far as I know, there is currently no simple answer to the bootstrapper problem, but I'll try to point you to some possible solutions:
I'm not familiar with the Bootstrapper Manifest Generator, but my understanding is that the VS bootstrapper is not very flexible. I remember I looked at it briefly and decided against it.
Since your question is tagged Wix I'll assume that you're aware of Wix 3.6's "Burn" bootstrapper currently in development. The present recommendation is that if you're planning to ship in the fall, you should pick up the Wix 3.6 dependency and start working with Burn. I consider this a very risky choice since there is no guarantee that Burn will actually be done in time.
I've used the Microsoft .NET Framework Setup.exe Bootstrapper Sample as the basis of a simple bootstrapper before. The idea here is to replace the logic to check for .NET Framework with logic to check for the SQL server you require. Then either install SQL Server by executing the redistributable, or skip the SQL Server installation and go straight into your MSI installation.
If you want to provide a user experience beyond regular MSI dialogs, you could look into creating an external UI, although documentation for this is scarce. I recently completed a WPF external UI bootstrapper. The way I tackled this was creating a C# version of the MsiSetExternalUI Handler Sample using Wix's DTF, and then integrated it into a WPF wizard based on this MVVM Wizard sample.
I hope that can at least get you started on choosing the right bootstrapper solution for your deployment. Good luck!