Windows installer xml toolset download. WiX Toolset

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. During the course of development, it’s important to have an automated build process.

Equally important is having an automated means of creating releases. Unfortunately, in many organizations-especially smaller ones-this doesn’t happen. Typically, you’ll find that the release is simply cobbled together at the last minute. However, if you take the time to set up an automated build and release plan, you’ll save countless hours that could be better spent on tasks other than building and releasing your project.

This article covers WiX v2 note that when WiX v3 is released, some of the syntax examples won’t translate directly. The techniques described here will be relevant whether or not you are using WiX to create your releases, though WiX does simplify the process. They can also be applied, with some modifications, to applications that are being developed without using the Microsoft.

NET Framework 2. I will provide an overview of the WiX toolset for those who are not familiar with it. You can get the latest sources at www. When creating an application, the end result is usually to install and run it on production machines. The WiX toolset can help you do this. WiX describes what the installation looks like on the target machine. You might be surprised to learn that WiX is actually an open source project and is hosted at sourceforge. You can download the latest binaries and sources at wix.

When you download and install WiX, you’ll find a number of executables installed as summarized in Figure 1. I will focus on using the Candle. WiX uses a declarative language, not a procedural one, which means you describe what your installation will look like, not what steps need to be followed in order to achieve it. This may be different from what you are accustomed to, but it is surprisingly easy to learn. Typically, your WiX source files will be populated by describing files that will be installed on the target machine.

I will focus on those components here. In a WiX source file, there are three main elements with respect to the files you intend to install: File, Component, and Feature. A File element is a reference to an individual file. Files must be contained in a Component element, which is the smallest unit to be installed. That is, if you have a component containing files and you install that component, all of its contained files are installed. Conversely, if that component is not installed, none of the files are installed.

Creating components that contain a large number of files is not recommended. Components are always contained in a Feature element and can be contained in more than one feature. A feature is a set of components and potentially of sub-features. If your installer has a graphical interface that allows the user to select which items to install, they are actually selecting features.

If IntelliSense is not enabled when you are editing a WiX source file using Visual Studio, all you have to do is copy the wix. Visual Studio has a tool that you can use for this purpose, and there are Visual Studio macros available so you can assign a shortcut to directly insert a new GUID as well. Now let’s start by creating a new WiX source file. The first element is always going to be a Wix element.

The type of desired output will drive which of these you will use. The beginning of the WiX v2 source file, Sedodream. As you can see ,the Product element has many attributes, the most important of which are Id and Name. The Id is used to uniquely identify the product.

You must change this for a new major release. You should also make a note of its value for later reference. The first child of the Product element, the Package element, is shown here as well. Notice that the Id attribute contains a series of? By using this syntax, the code specifies that the Id should be generated at build time. When you are creating installers, you want the Package Id to be different for each installer created, even from one build to the next. Almost every installer will place at least one file onto the target machine, and this installer is no different.

Since WiX uses a declarative approach, I’ll declare what the directory structure is and that will be recreated on the target machine. I do this using a series of Directory elements:. The Media element in this sample specifies that a cabinet file will be generated and placed into the installer database. This is a required element, and if you have installations spanning more than one medium you can have more than one.

For example, if you are distributing your application on a CD, but it needs to span over multiple discs. In most cases, you won’t have to worry about this issue. Following Media is the series of Directory elements. The first Directory element will be a virtual element that simply encapsulates the other entries. As you may have guessed, this is a well-known location and Windows Installer will set its value when launched. There are other system folders you can use; a complete list is available from msdn.

These system properties always resolve to their full paths. The next elements provide names of custom directories. The directory will be named using the LongName attribute if possible; otherwise the Name attribute is used. If those directories don’t exist, Windows Installer will create the appropriate one at install time.

After you declare your directory structure, it’s time to start creating Component declarations. As noted earlier, the smallest unit that can be installed is the component, which can consist of many different items including files, shortcuts, registry keys, and certificates. Design your components so they are independent of each other.

That is, when you install or uninstall a component there should be no adverse effect on other components. Inherently this means that items should only be contained in a single component. If that’s not the case, you may want to reconsider how your components are organized. It’s not unusual for a component to contain only a single file.

It is very important to ensure that none of your component GUIDs repeat. Figure 2 shows a component from the sample WiX source file. You can see that it contains four File elements and two XmlFile elements. The File element is simply a reference to a file that needs to be placed on the target device. It inserts a new element into the Microsoft. Features are the items that the user will select for installation if your installer shows a UI. Here are the Feature declarations from the sample project:.

Like many other WiX elements, the Feature element has many possible attributes, some of the more commonly used ones are described in Figure 4. In this WiX snippet the main feature, Complete, contains a reference to two components and a sub-feature. The sub-feature references are achieved by a child Feature element.

The WiX source file can contain as many of these as necessary. The component reference uses a ComponentRef element. When using the ComponentRef element you have to use the same ID value that is used in the Component element you are trying to reference. In the latest releases for WiX v2 you’ll find a wix. Those tasks are all contained in the WiXTasks. The way in which you’ll build installers is very similar to how managed projects are built now.

For example, when creating a C project, your project file will contain all the necessary properties and items to build the project, but all the steps to build the project are contained in the Microsoft. This file is included into the project file with the MSBuild Import element. For WiX, your project file will define all necessary properties and items and then include the wix.

Figure 6 provides a list of the minimum declarations required to successfully build an installer using wix. To create the installer you need to create an MSBuild file to define the required properties and items. This file is shown in Figure 7. As you can see, there’s not much to this MSBuild file, just a few properties and a lone item defined.

The file assumes that a WiX source file, Sedodream. The WiX file also makes some assumptions about where files are placed. For now let’s assume that all the files are where they need to be. To build the installer I will need to invoke MSBuild on the project file. I open the Visual Studio command prompt, navigate to where the file resides, and execute the following command:.

Since I didn’t define a target to execute, the DefaultTargets were executed, and this was defined to be Build in the Sedodream. From the output you can see that a file named ReleaseSedodream.

At this point you can execute the installer to ensure that it works as expected.

 
 

 

Windows Installer v2 () is available – Microsoft Support.GitHub – kurtanr/WiXInstallerExamples: Installer examples created using WiX toolset

 

Release Date: May 12, For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:. Microsoft used the most current virus-detection software that was available on the date that the file was posted.

The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file. Note Only the binary for the Msi. The version number is 3. All other binaries of the Windows Installer 3. This redistributable component is only for bit operating systems. You cannot install this component on a computer that is running the bit versions of Windows Server or of Windows XP.

You can install Windows Installer 3. Windows Installer 3. You cannot install this redistributable on the bit and bit versions of Windows Server SP1. To update the bit and bit versions of Windows Server SP1, or to update the bit versions of Windows XP, download the hotfix that is described in Microsoft Knowledge Base article instead of the v2 package. Release history:. New minor UpdateTargetRTMProperty property: Patch files can now target both the original release baseline and the latest service-pack-level baseline that is on the system.

New x64 and Msix64 properties: Packages can now use the x64 and Msix64 properties to indicate x64 processor-based operating system support. Flyweight patching is now an opt-in behavior: Windows Installer 3. By default, this functionality was enabled for all patches. The MsiGetFileHash function now works correctly for very large unversioned files. These files may be about 2 GB. The MediaSrcProp property of a patch is now set to the original launched-from location when the patch is installed.

The MediaSrcProp property is set to the cached patch location for subsequent transactions. Target information for a custom action is no longer logged when the custom action fails if the custom action is marked to hide the target. Applying a full-file Windows Installer 2. Sequence column of File table includes values larger than In Windows Installer 3.

This issue is now fixed. The patch sequencer no longer incorrectly rejects a valid patch during administrative image patching. Windows Installer no longer fails silently when the installer tries to update a file that is protected by the Windows File Protection feature.

For help in troubleshooting Windows installer issues, click the following article number to view the article in the Microsoft Knowledge Base:. Sign in with Microsoft. The next elements provide names of custom directories.

The directory will be named using the LongName attribute if possible; otherwise the Name attribute is used. If those directories don’t exist, Windows Installer will create the appropriate one at install time.

After you declare your directory structure, it’s time to start creating Component declarations. As noted earlier, the smallest unit that can be installed is the component, which can consist of many different items including files, shortcuts, registry keys, and certificates. Design your components so they are independent of each other. That is, when you install or uninstall a component there should be no adverse effect on other components.

Inherently this means that items should only be contained in a single component. If that’s not the case, you may want to reconsider how your components are organized. It’s not unusual for a component to contain only a single file.

It is very important to ensure that none of your component GUIDs repeat. Figure 2 shows a component from the sample WiX source file. You can see that it contains four File elements and two XmlFile elements. The File element is simply a reference to a file that needs to be placed on the target device. It inserts a new element into the Microsoft. Features are the items that the user will select for installation if your installer shows a UI.

Here are the Feature declarations from the sample project:. Like many other WiX elements, the Feature element has many possible attributes, some of the more commonly used ones are described in Figure 4. In this WiX snippet the main feature, Complete, contains a reference to two components and a sub-feature.

The sub-feature references are achieved by a child Feature element. The WiX source file can contain as many of these as necessary. The component reference uses a ComponentRef element. When using the ComponentRef element you have to use the same ID value that is used in the Component element you are trying to reference. In the latest releases for WiX v2 you’ll find a wix. Those tasks are all contained in the WiXTasks.

The way in which you’ll build installers is very similar to how managed projects are built now. For example, when creating a C project, your project file will contain all the necessary properties and items to build the project, but all the steps to build the project are contained in the Microsoft. This file is included into the project file with the MSBuild Import element. For WiX, your project file will define all necessary properties and items and then include the wix.

Figure 6 provides a list of the minimum declarations required to successfully build an installer using wix. To create the installer you need to create an MSBuild file to define the required properties and items. This file is shown in Figure 7. As you can see, there’s not much to this MSBuild file, just a few properties and a lone item defined. The file assumes that a WiX source file, Sedodream. The WiX file also makes some assumptions about where files are placed. For now let’s assume that all the files are where they need to be.

To build the installer I will need to invoke MSBuild on the project file. I open the Visual Studio command prompt, navigate to where the file resides, and execute the following command:. Since I didn’t define a target to execute, the DefaultTargets were executed, and this was defined to be Build in the Sedodream.

From the output you can see that a file named ReleaseSedodream. At this point you can execute the installer to ensure that it works as expected.

Before continuing with our main goal, I will cover an advanced MSBuild topic, batching, in the next section. This is necessary because batching is used throughout the process that will build the product and its release. When using MSBuild you’ll discover that there is no looping construct to be found. In place of a loop you can employ batching, which uses item metadata to break items into different categories called batches or buckets that consist of one or more items.

Once the items are separated you can iterate through each batch. This is used throughout the build process for managed projects. There are two broad categories of batching: task batching and target batching. In task batching, when you execute a task, the MSBuild engine will determine what buckets need to be created and execute the task over those buckets.

To use task batching, you provide an item’s metadata to the task. To demonstrate batching, imagine you are faced with the following scenario. You have to copy a set of files from one location to one or more other locations and you have two options: you can copy the files using individual Copy tasks to each location, or you can use batching to achieve this in one copy element. The first approach, although simple, is not a good solution because it is difficult to maintain.

To illustrate the second approach, have a look at this very simple MSBuild file, batching In this file, I declare an item SourceFiles to include any file that ends with. This is task batching. To execute this I can invoke the following command from the directory that contains the batching Now I’ll demonstrate the same result with target batching.

For target batching, the batches are created based on the Inputs and Outputs of the target so I have to pass an item’s metadata for these values:.

Target batching is driven off of the targets Inputs and Outputs. Since Outputs contains the Dest. FullPath declaration the target will be invoked once per bucket. This is similar to task batching, except that the contents of the entire target will be repeated once per batch, as shown in Figure 9. From this output you can see that the target, CopyFiles, was invoked once per batch for the Dest item. For each organization the steps involved to build and package are going to be slightly different, in some cases due to the technologies used, and in others because of organizational requirements.

I have put together a set of steps that I think will serve many organizations well, though it may require some fine tuning based on your particular scenario. The goal of an automated build-and-package process is twofold: to create a repeatable public build process and to create an automated repeatable package process.

There are three core steps: get latest, build, and package, but this is broken down into many smaller steps as shown in Figure A very important step is labeling the sources.

This is a requirement because without this step you would not be able to repeat the process. When you create a build that will be sent for production, you need to be able to recreate that exact same build in order to maintain the deployed code. This step will be different based on the tool you are using for your source control provider. There are many different MSBuild tasks available for download to achieve this for various source control providers.

In this section, I’ll introduce the MSBuild script that can be used to build and package the sample application. The overall structure is very similar to how managed projects are built.

That is, you’ll define a project file that contains what should be processed, and you import another project file, Sedodream. Think of these processes as sentences. Your packaging project file defines the nouns and the imported file defines the verbs.

I will build the project by using the MSBuild task on the Solution file. To build the installer, the previous project file, SedodreamMSI.

When you have a process that has segregated elements, they somehow need to be brought together. This is done by defining a common set of properties, items, and targets see Figure In this process, the solution will be built and the WiX source files will be copied into that same directory.

You should define your WiX source files keeping this path in mind. Regardless of where your WiX files are contained in source control, they will be built from the same directory that the product is built to.

Other required files are also copied to this same directory by the CopyFilesForPackaging target. Also in this process, the PackageRoot property will define where the projects are built and where WiX will build the installers. In the sample, the directory is at the same level as the solution file, but it could be anywhere on the build machine-though I recommend not using a network share for this location.

The main targets declared in the Sedodream. All of these targets and many others in the targets file have their dependencies defined in properties so you can completely change the sequence of events in the process. For example, if you needed to inject a step before the Build target executed your project file, you could simply insert the following snippet after the Import statement for the Sedodream. Because the BuildDependsOn property was redefined, you effectively inject the CustomBeforeBuild step into the current process without modifying the existing targets file.

For a more detailed discussion of this issue, you should take a look at my June article referenced previously.

Before creating the installer, let’s have a quick look at the CoreBuild target that builds the solution see Figure This will demonstrate how target batching is used to build the solution for each defined configuration.

Then, the MSBuild task is called to build the solution file with all the appropriate properties. The OutputPath is provided because I want to redirect the output to another directory. The only remaining issue with regard to creating the installer for the sample project is creating the MSBuild project file to define the required properties.

This is surprisingly simple. Finally, I’ll show you how to customize the process to suit your needs. Figure 14 shows the MSBuild file, Sedodream. As discussed earlier, the main purpose of this project file is to describe what needs to be built. The imported file, Sedodream. In this project file, you see the required SolutionFilePath property defined. This is the path to the solution file that will be used to build the product. Also, you see the declaration of the WixSourceFiles item, which includes the set of files that will be used to compile your installer.

These are the files that will be sent to the Candle. Along with this is the declaration of the OtherFiles item, which contains files that should be copied to the location that will be used to create the installer.

These files will be copied to the BaseInputPath that will be used to create the installer. You can have them copied to any location underneath that by using the Destination metadata value. In this example, I am copying custom bitmaps to be used to generate the installer into the bitmaps folder. When the Light. Note the declaration of the DropLocation property. By declaring this property, all the files in the PackageRoot will be copied to a directory in the DropLocation. It’s helpful to have the binaries and installer files in one location, in case you need to make some quick modifications.

To see the build and package executed for the sample project, open a Visual Studio command prompt and navigate to the projects deployment folder. Then execute the following command:. Lots of output is generated to the command prompt, and you will find two directories, Debug and Release, under the Package directory.

Each of these directories will contain the generated installer and its associated files. When you set up this process for your product, you will need to create a file similar to the SedodreamPackage.

You can place your customizations directly inside that file.