September 9, 2009 at 13:53Creating an installer using WiX. Part 2
Last time, we learned how to create a simple installer . Before we move on, from simple to complex, let's learn how to manage this most complex. Namely, we will learn how to split a project into parts in order to simplify maintenance and changes.
Our first project consisted of one single file, in which all instructions for the installer were written. One file was installed (calculator). Now imagine a more serious project, including, for example, 10, 20, or even 100 files. If we include a description of these files in the project file, then later, when we need to change something, we will understand that it is very difficult to search for something specific in this heap.
Based on the previous project, we take out the description of the installed files outside the project fileProduct.wxs . To do this, add the Files.wxs file to the project , define the following content for it:
We will delete the component description from the Product.wxs file so as not to get an error message during the project build process.
It was
Has become
Two new keys appeared in the code and .
contains inside a piece of code that will be included in the project during assembly.
Link to the Directory section. Allows you to take, for example, the description of components beyond the key.
By the way, keys of the form <* Ref> simplify the process of dividing a project into fragments, and help organize the code. Besides there are links ,other.
To complicate the project a bit, add a notepad installation to it. We modify the code as follows:
Added. What is embarrassing? The path to each file. What if the files are migrated? But what if there are 100 of them? Searching with a replacement will help, but this is not our method. Meet the new key parameter- FileSource. This parameter allows you to set the base path. We will rewrite with the new knowledge, at the same time we will put DiskId = '1' into the component definition. Why should it be indicated every time if all child elements use the same value?
Note that the Key source parameterhas been changed to Name. Those. we instructed to search by file name inside the specified directory, and not by the absolute path of the file. If this is not done, then we will receive the error message "cannot find the specified file."
Notepad added, add a shortcut to it. We find the creation of a shortcut for the calculator and see porridge. The component for creating a shortcut is described inside the directory. Take out the creation of shortcuts in a separate file. To do this, add the Shortcuts.wxs file to the project :
If we try to build the project now, we get the error message: Undefined preprocessor variable '$ (var.ProductName)'
That's right, nothing is known about the variables declared in the Product.wxs file when processing the Shortcuts.wxs file . What to do? In addition to fragments, WiX allows you to use include files (include). The contents of such a file can be defined as follows:
Unlike a fragment, include will not be automatically included in the assembly until you include it in any file yourself. In order to understand what inclusion is, let's put the definition of variables from the Product.wxs file into a separate file. To do this, add a new Variables.wxi file to the project , and transfer the variable declaration into it:
And the definition of the variables in the Product.wxs file is replaced by:
Also, do not forget to add the same line to the Shortcuts.wxs file . After that, the installation package should compile without errors.
There was one file Product.wxs became four files. For a simple installation package, perhaps such a fragmentation does not make sense, especially if this package is written at once. For a large project, including installing dozens of files, creating shortcuts - separation is vital. Otherwise, in such a project, as the saying goes, the devil will break his leg. Another advantage of using fragments is the ability to reuse ready-made code.
Next time, we will add to our package the ability to select components for installation and add a “home-made” window in which the user can change the installation options.
Sources and project for Visual Studio can be downloaded here
Our first project consisted of one single file, in which all instructions for the installer were written. One file was installed (calculator). Now imagine a more serious project, including, for example, 10, 20, or even 100 files. If we include a description of these files in the project file, then later, when we need to change something, we will understand that it is very difficult to search for something specific in this heap.
Based on the previous project, we take out the description of the installed files outside the project fileProduct.wxs . To do this, add the Files.wxs file to the project , define the following content for it:
* This source code was highlighted with Source Code Highlighter.
We will delete the component description from the Product.wxs file so as not to get an error message during the project build process.
It was
* This source code was highlighted with Source Code Highlighter.
Has become
* This source code was highlighted with Source Code Highlighter.
Two new keys appeared in the code
By the way, keys of the form <* Ref> simplify the process of dividing a project into fragments, and help organize the code. Besides
To complicate the project a bit, add a notepad installation to it. We modify the code as follows:
* This source code was highlighted with Source Code Highlighter.
Added. What is embarrassing? The path to each file. What if the files are migrated? But what if there are 100 of them? Searching with a replacement will help, but this is not our method. Meet the new key parameter
* This source code was highlighted with Source Code Highlighter.
Note that the Key source parameter
Notepad added, add a shortcut to it. We find the creation of a shortcut for the calculator and see porridge. The component for creating a shortcut is described inside the directory. Take out the creation of shortcuts in a separate file. To do this, add the Shortcuts.wxs file to the project :
Name="Calc"
Description="$(var.ProductName)"
Target="[INSTALLLOCATION]Calc.exe"
WorkingDirectory="INSTALLLOCATION"/>
Name="Notepad"
Description="$(var.ProductName)"
Target="[INSTALLLOCATION]Notepad.exe"
WorkingDirectory="INSTALLLOCATION"/>
* This source code was highlighted with Source Code Highlighter.
If we try to build the project now, we get the error message: Undefined preprocessor variable '$ (var.ProductName)'
That's right, nothing is known about the variables declared in the Product.wxs file when processing the Shortcuts.wxs file . What to do? In addition to fragments, WiX allows you to use include files (include). The contents of such a file can be defined as follows:
* This source code was highlighted with Source Code Highlighter.
Unlike a fragment, include will not be automatically included in the assembly until you include it in any file yourself. In order to understand what inclusion is, let's put the definition of variables from the Product.wxs file into a separate file. To do this, add a new Variables.wxi file to the project , and transfer the variable declaration into it:
* This source code was highlighted with Source Code Highlighter.
And the definition of the variables in the Product.wxs file is replaced by:
* This source code was highlighted with Source Code Highlighter.
Also, do not forget to add the same line to the Shortcuts.wxs file . After that, the installation package should compile without errors.
There was one file Product.wxs became four files. For a simple installation package, perhaps such a fragmentation does not make sense, especially if this package is written at once. For a large project, including installing dozens of files, creating shortcuts - separation is vital. Otherwise, in such a project, as the saying goes, the devil will break his leg. Another advantage of using fragments is the ability to reuse ready-made code.
Next time, we will add to our package the ability to select components for installation and add a “home-made” window in which the user can change the installation options.
Sources and project for Visual Studio can be downloaded here