Original address: http://blog.csdn.net/rryqsh/article/details/8274832
Visual Studio package installs seven deadly sins
Development. NET will certainly use the MSI Package Installation tool framework that is included with Visual Studio. In general, this packaged installation framework is fully sufficient to meet the needs of the product release installation. It's finished product, is a Setup.exe, an MSI installation file, if you choose the project since the other. Net,windows the install framework, and determines that it will be released with the products, and that the finished item also contains the installation files for these items.
However, the installation experience of the VS package release is really poor, for example, if your project is dependent on. NET 4.0 and VC + + 2010, and your target client does not have any such products installed, then when you execute Setup.exe, you will first pop up. NET 4.0 The customer installs the agreement, the user clicks "agrees", then pops up the VC + + 2010 Customer installs the agreement, the user clicks "agrees" again, can begin the real installment. And in the installation process, every thing installed, if it is on the system above the Vista, it will pop up once need to confirm the installation and enhance the permissions of the dialog box, it is patience.
And this packaging option is also very strange, if you will use the Installer publishing tool, you will remember that there will always be only in the "Web download the required dependencies" and "locally contains the required dependencies" in two selected. If I want to customize the release of the installation package, if you find that the dependency does not exist, then automatically go to the Internet download it? Sorry, I can't do that. And if the MSI I'm packing out is Chinese, it's definitely going to be taken when it's released. NET's Chinese language pack. If the system is not modified bootstrapper configuration, this language pack is must follow, it is completely unreasonable, my product is multi-language installation, is not. Does the net also need multi-language packs?
Some basic concepts that must be mastered
The full name of WiX is (Windows Installer XML), in short, the use of XML to configure and customize the individual installation scenarios. Some of these are called Burn, which is the bootstrapper development framework to be highlighted in this article, and the other part is the Setup development framework.
First of all, the difference between Bootstrapper and MSI, MSI is a new set of Microsoft installation solution, relying on Microsoft install Service, in fact, MSI can be understood as a set of strong format of the installation library, the MSI file contains a series of data structures and files, The data structure describes such configuration information as which directories to create, which registry keys to create, which files to copy, what shortcuts to create, and all file data that needs to be copied for publication. The installation service then passes these configuration information, reads and steps through, and finally completes an MSI installation process. The MSI file is a more powerful ZIP file installation package.
The problem is that if your West is developed using pure C + +, then just one MSI release will solve the problem because it will not depend on anything else to execute directly. But since you're using Microsoft's stuff, now. NET is almost a framework that must be covered on Windows, and most programs will depend on. Net. This is the problem, what if. NET is not installed on the client machine? You can't just. NET is released together in your MSI. This time you need to determine the installation of the MSI before the installation of the environment, such as the installation of. NET, if you have installed it will not be installed, of course, some other frameworks need to be judged, these early judgment of the things MSI can not do, of course, your program can not do, because there is no. NET environment Ah, your program is used. NET Write! Isn't this the problem of chickens having eggs and chickens?
These problems actually Microsoft also thought of, So they made a simple setup.exe, you see, this is an EXE file, do not rely on any other framework, this EXE will first determine the system environment, and make the need to download the installation of other framework decisions, and then after the basic environment is done, you can install our MSI. This exe, is called bootstrapper.
WiX Bootstrapper Development Tutorials
The above mentioned problems can be solved in WiX, of course you can even not use the VS Package publishing tool, because we already know that WiX can develop its own MSI, just text on this no longer detailed, VS's packaging tools to create an MSI, Again with WiX bootstrapper installation, complement each other, save time and effort, WiX after all, only XML to write, or is very troublesome.
First, we download the WiX toolset installation file in Http://wixtoolset.org/releases, and the VS 2010 seems to support up to 3.7 versions, then click on the middle gear's line install to frame the installation. This tool is supported vs plug-in, after the installation is completed, there will be a project type "Wix toolset" in VS, and when we select "Bootstrapper project", we can create a new project. We are developing our bootstrapper in this project.
Once created, a bootstrapper project will be available, with the Bundle.wxs file, which is the package installation configuration file. All XML elements can be queried by http://wix.sourceforge.net/manual-wix3/schema_index.htm, with the default code as follows:
[HTML]View Plaincopy
- <? XML version= "1.0" encoding="UTF-8"?>
- <Wix xmlns="Http://schemas.microsoft.com/wix/2006/wi">
- <Bundle name="Bootstrapper1" version="1.0.0.0" manufacturer= "" Upgradecode="5240b0e0-2b53-44c9-9837-05e9a4b63dbc">
- <bootstrapperapplicationref id="wixstandardbootstrapperapplication.rtflicense" />
- <Chain>
- <!--todo:define The list of chained packages.
- <!--<msipackage sourcefile= "Path\to\your.msi"/> --
- </Chain>
- </Bundle>
- </Wix>
Let's take a look at the tag element to see how this file affects the running
Bundle, this is the root node for all configurations, where name is the product name that we publish, customizable, and note that the name appears in the title bar of the installation dialog box and in the list of uninstaller programs. Version is the release number, manufacturer is the developer name, these will appear in the Uninstaller list, Updatecode is a very important property, if the two product updatecode like, That version of the larger product will automatically uninstall the small version of the program before installation, that is, automatic overwrite installation. These concepts are common to all installation frameworks.
Bootstrapperapplicationref This concept is more complex, according to my experience, this is the use of the already defined installation framework template, id= " Wixstandardbootstrapperapplication.rtflicense "is an already existing installation framework interface, indicating that the bootstrapper execution will display a Client Installation agreement dialog box, the text in the dialog box can be customized. We'll cover the detailed customization of this element in a later space.
Chain, this is the sequence that represents the installation, all the custom installation order is done in this node, such as we can first define the installation a.exe, then install B.msi, then install C.MSP, etc., can be configured in this node.
Let's edit the Wxs file, specify the property contents of the bundle/@Manufacturer, and add a child node to the chain, which must have a child node in the chain node. We can randomly generate an. msi installation file, copy it into our bootstrapper project, and then add the child element MSI in chain, and generate the project, and the final Wxs file is as follows:
[HTML]View Plaincopy
- <span style="FONT-SIZE:12PX;" ><? XML version= "1.0" encoding="UTF-8"?>
- <Wix xmlns= "http://schemas.microsoft.com/wix/2006/wi" xmlns:bal="http// Schemas.microsoft.com/wix/balextension ">
- <Bundle name="Demowixbootstrapper" version="1.0.0.0" manufacturer= "Vanpan" Upgradecode="5240b0e0-2b53-44c9-9837-05e9a4b63dbc">
- <bootstrapperapplicationref id="Wixstandardbootstrapperapplication.rtflicense"/>
- <Chain>
- <msipackage sourcefile="Setup1.msi"/>
- </Chain>
- </Bundle>
- </Wix></span>
One of the Setup1.msi files is to take an install finished MSI with VS generated, and you can also replace it with your own project MSI. After the build, in the Debug folder of the project, you will see that there is a Bootstrapper1.exe file, size than we put in the setup1.msi slightly larger, in fact, this is the MSI packaged into the installation EXE results. Double click EXE, you can see the installation screen.
We see that the title bar is our custom bundle/@Name property content, you can click on the Install button to experience the effect of the installation, of course, this is a very rough sample. Please be assured that this framework will definitely not be as simple as you think. Our later articles continue to explain how to customize the installation sequence, customize the installation protocol, localize the installation interface, and even adjust the installation interface layout.
Create a. NET program release bootstrapper using WiX toolset (Installation policy Management) (i)-----first knowledge of WiX (GO)