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!
Related
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.
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 have custom bootstrappers for SQL Server 2008 R2, .NET Framework 3.5, .NET Framework 4, etc. I am using Visual STudio 2010's Deployment project to deploy a .NET 4 application. I know these are going away.
Is there a way I can specify a bootstrapper to Fail if the user does not have specific Windows Privledges? SQL Server's Setup seems to take care of this on its own, but gives very cryptic error codes and texts that are hard to trace for users. I know that I can set Bypasses for Windows versions, and SqlCheck.exe performs some sort of version check. Would I have to create my own application that checks the user's permissions, and the bootstrapper could check the return code of that, similar to SqlCheck.exe?
Can this be accomplished using the Bootstrapper Manifest Generator, and is the BMG even supported by Visual Studio 2010? Appears to not be supported anymore, but I"m not sure if there's anything specific to VS 2010 / Windows Installer 4.5
http://archive.msdn.microsoft.com/bmg
The most you can do with the standard Visual Studio bootstrapper is to check the AdminUser property value. The predefined .NET Framework 4.0 Client Profile prerequisite uses a similar condition. You can find its manifest in this folder:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client
This should also be supported by the bootstrapper manifest generator.
But, and this is a big one, on newer Windows versions all users can get Administrator privileges through elevation. So from the installer point of view, any user is seen as an Administrator, even if he's not.
So this approach is pretty much useless on Vista or higher.
You could try creating your own custom EXE bootstrapper which handles prerequisites and checks user privileges. But you will most likely encounter the same problem.
From my experience, the best approach is to let each installer elevate itself if necessary. Most of them have built-in mechanisms for this, especially the ones from Microsoft.
If you encounter problems with this approach, I'm pretty sure they are not caused by privileges. Most likely your prerequisite is not configured correctly (for example an incorrect command line).
I want to perform a .NET CF 2.0 build using VS2010. I know it's not supported "normnally," but I've seen this answer: ( .NET Compact Framework with Visual Studio 2010? ) ...and I want to use that approach.
The blog post cited there says I need to modify the .csproj files for the .NET CF projects, to point to a particular Microsoft.CompactFramework.Common.targets . But I don't have that file.
I figured I needed to install the Windows Mobile 6 Standard SDK to get it.
I tried installing it and get this:
I have seen this question:
Windows Mobile 6 Standard SDK Refresh install issue on Visual Studio 2010 Professional Beta 2
I don't think the solution proposed there is workable for me. I do not have VS2008. I do not have VS2005. I have only VS2010, and I have no installable media for those other products.
I have also tried the administrative install (msiexec /a), but the resulting directory structure doesn't contain any files like Microsoft.CompactFramework.Common.targets .??
Q1:
Is there a way for me to install WM6 Standard SDK?
Q2: Anyone know the reg key that it looks for to determine if I have the appropriate pre-reqs?
Is this going to work if I just fiddle with my registry?
Q3: Is my assumption wrong? Really I want the Microsoft.CompactFramework.Common.targets file and its friends. Where can I get this? (I have no existing VS2008 machine to suck from)
Q4: Another approach I can think of is getting an eval version of VS2008, installing that into a VM, then installing the WM6 Std SDK there, then grabbing the Microsoft.CompactFramework.Common.targets file from that. Long way round. Is this gonna work and is it worth the trouble?
ANSWER
Here's the answer.
It is possible to build CF apps with VS2010, as outlined in Joel Fjorden's blog post. There are pre-requisites you need, in order to make this happen.
I believe the only official way to get the required files, including Microsoft.CompactFramework.Common.targets , Microsoft.CompactFramework.CSharp.targets , Microsoft.CompactFramework.VisualBasic.targets and Microsoft.CompactFramework.Build.Tasks.dll , is to install the related version of Visual Studio. These files are all version-specific, so to get the files for building for .NET CF 2.0, you need to install VS2005, and for .NET CF 3.5 you need to install VS2008. Installing VS2010 gives you neither. It works to use eval versions of the tools. It worked for me anyway.
If you are willing to go custom, you can simply copy these files from a working installation of VS2005 or VS2008 (or both), into the appropriate .NET directory, usually something like C:\Windows\Microsoft.NET\Framework\v2.0.50727 (change the version as appropriate). Chris Tacke has helpfully posted a link to the files you need. I don't know if copying these files violates the license for VS20?? , I am not a licensing expert.
You cannot get these files from the Windows Mobile SDK, as far as I can tell. Even so, you might still want a version-specific mobile SDK to get the emulators and skins and so on.
This is a basic "build" capability. It works but it doesn't give you designer support, debugging capability, built-in project templates, and so on. My advice to anyone who wants to do forward development on .NET CF is to use the tools that are geared toward those tasks - VS2005 or VS2008.
Thanks to Chris Tacke for posting a link for the files.
Not sure if it's any help, but the CF targets files from VS2008 can be found here. Let us know if you make any progress.
The "Power Toys for .NET Compact Framework" package (currently found at http://www.microsoft.com/en-us/download/details.aspx?id=13442) also contains the required files.
Thought I'd leave that here since it's an official Microsoft download.
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.