C#中最强大的开源软件源代码

 SharpDevelop Setup Build Server Rules ------------------------------------- All new .msi files are treated as major upgrades on the build server: http://msdn.microsoft.com/library/en-us/msi/setup/major_upgrades.asp 1) Package code always changes for a new revision. 2) Product version is updated with the revision number. 3) Product code changed for a new revision. 4) Msi filename changed on each build. It includes the SharpDevelop version and revision. Guid generation --------------- The Guid generation is done by WiX itself. Only the version number is generated by the buildSetup.bat file. This file runs the UpdateSetupInfo tool. The UpdateSetupInfo tool reads the current revision number and updates the installation. This information is stored in the SharpDevelop.Setup.wixproj.user file which is generated each time when run from the build server. The Wix setup documents have preprocessor variables $(var) that map to MSBuild properties. These MSBuild properties are stored in the SharpDevelop.Setup.wixproj.user file. The SharpDevelop.Setup.wixproj.user file is in the repository since but it is not committed on each build. Therefore the Product Code guid is not stored anywhere apart from the .msi itself. This maybe a problem. The Upgrade Code is the important guid and that is in the main Setup.wxs file and should not be changed. It will be changed for SharpDevelop 3.0. The UpdateSetupInfo tool is not used when building the SharpDevelop.Setup project. The buildSetup.bat does use the tool. The build server also uses the tool. The UpdateSetupInfo tool uses a template file SharpDevelop.Setup.wixproj.user.template which is stored in the repository and has a placeholder for the revision number. If the build server generates two installer packages with the same revision number but different Product code guids then the user can install two instances of SharpDevelop 2.1 on their machine which we do not want. However the installer is only generated on the build server if the revision has changed. Why major instead of minor? --------------------------- It allows us to make large changes to the installer, completely restructuring the features, components, and renaming the .msi filename. Just renaming the .msi filename on its own means the product code guid has to change. However the main reason is that to use a minor upgrade so it upgrades the existing installation you have to use a command line like: msiexec /i SharpDevelop.msi REINSTALL=ALL REINSTALLMODE=vomus Otherwise you just get a message informing you that there is an existing installation. A major upgrade is more user friendly and will not need such a command line, it should install just by double clicking the .msi. SharpDevelop Setup Rules ------------------------ 1) Each assembly (.exe, .dll) added gets its own Component. This includes any files that logically belong to it (e.g. .config, .addin), but not any assemblies it uses (.exe, .dll). For an added assembly the File element should look like: <File Id="SharpDevelopExeId" Name="SharpDev.exe" LongName="SharpDevelop.exe" Source="..\..\bin\SharpDevelop.exe" Assembly=".net" AssemblyApplication="SharpDevelopExeId" AssemblyManifest="SharpDevelopExeId" KeyPath="yes"/> Note that the Id is typically just the filename, but the in the example I have emphasised that AssemblyApplication and AssemblyManifest refer to the file id. Windows Installer References ---------------------------- Windows Installer has a lot of rules that need to be followed when creating setup packages. The main ones to look at the rules for adding/removing components. The documentation is a bit confusing, some parts say that you need to generate a new Component Guid when you add/remove a resource (file, registry, etc) to/from a component. Other parts say that with Windows Installer v2 you can add/remove resources without needing to regenerate a new guid. SharpDevelop's installer will not allow side-by-side installations of SharpDevelop 2.1. Each new installer will be able to upgrade all previous versions from 2.1.0 upwards. Disallowing side-by-side installations should prevent any problems if component Guids are not altered when they should be (see What Happens if the Component Rules are Broken?) SharpDevelop component rules: 1) Never the same resource into two different components. 2) All resources in a component must be installed into the same directory. 3) When adding a new file to an existing directory put it inside its own new component. That is if a previous version of the installer has been released. If you're adding a completely new addin this does not apply, each .exe and .dll should be in its own component, but other files can be grouped. 4) Removing a file. According to the docs: "you must also change the name or target location every resource in the component." This is not a problem for .exe and .dlls since they should be in their own component so you just remove the entire component. If you may remove the resource at some point in the future, put it into its own component. If you have to remove a file from an existing component change its guid and hope nothing breaks. Setup Package Validation ------------------------ Orca is no longer required as building the installer runs a post build task that validates the generated installer. Do not ignore any errors. Warnings need to be understood before being ignored. ICE33 warnings can be ignored - see the Setup.wxs file for more details. http://msdn.microsoft.com/library/en-us/msi/setup/organizing_applications_into_components.asp http://msdn.microsoft.com/library/en-us/msi/setup/changing_the_component_code.asp http://msdn.microsoft.com/library/en-us/msi/setup/what_happens_if_the_component_rules_are_broken.asp http://msdn.microsoft.com/library/en-us/msi/setup/defining_installer_components.asp http://msdn.microsoft.com/library/en-us/msi/setup/assemblies.asp http://msdn.microsoft.com/library/en-us/msi/setup/patching_and_upgrades.asp http://msdn.microsoft.com/library/en-us/msi/setup/changing_the_product_code.asp http://msdn.microsoft.com/library/en-us/msi/setup/minor_upgrades.asp Rob Mensching also has some information about the component rules on his blog: Windows Installer Components Introduction http://blogs.msdn.com/robmen/archive/2003/10/04/56479.aspx Component Rules 101 http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx