Categories
Windows Installer, Application Compatibility and Deployments

Webinar: Expanding Agile Practices to Software Installation Development

Commercial and enterprise developers face the challenge of developing and deploying new applications with agility. An important part of agile methodologies is the ability to quickly add and test new features, and deploy those features for immediate business use. Watch this Webinar from Visual Studio Magazine to learn how to build software installations according to agile best practices.

Webinar: Expanding Agile Practices to Software Installation Development
Date: Available to view now

In this on-demand Webinar from Visual Studio Magazine, learn about the challenges that agile teams face in building and deploying applications rapidly and how best practices in installation development strategy and technology are key to the success of any agile development team.

Learn how:

  • Agile methodologies are designed to support rapid application building and deployment at any time
  • Application installation development has moved from an individual to a team effort
  • Best practices can accelerate application building and deployment while also ensuring a high-quality installation experience
Categories
Events Microsoft Windows Installer, Application Compatibility and Deployments

Webinar: Best Practices for Building Installation in Visual Studio 2010

Long-time Visual Studio developers understand that the Visual Studio Installer (VSI) tool is not ideal for most installation projects. It may look OK at first glance, but you soon realize VSI has many deficiencies, including:

  1. Visual Studio 2010 LogoCan’t manage components and features
  2. Can’t customize dialog boxes
  3. Can’t validate MSIs for Microsoft® Logo Guidelines
  4. Limited support for custom actions
  5. Can’t create updates and patches

Watch this Webinar from Flexera software to learn best practices for building reliable Windows Installer (MSI) installations inside the Visual Studio 2010 interface. Long-time Visual Studio developers understand that the Visual Studio Installer (VSI) tool is not ideal for most installation projects.

This Webinar explains how the world’s top software companies build reliable MSI installations inside Visual Studio 2010 using InstallShield. If you use Visual Studio 2010 to develop applications – and especially if you work in a large enterprise-level development environment – this Webinar is for you.

Learn best practices for building reliable Windows Installer (MSI) installations inside the Visual Studio® 2010 interface.

  • Webinar: Best Practices for Building Installations in Visual Studio 2010
  • Presenter: Robert Dickau, Flexera Software
  • Date: Available now for viewing

View this webinar now : Click here

PS: You will need to enter your contact information, looks more for product marketting purpose!

You would also be interested in reading –

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

Did you know these Windows Installer File Types?

This post defines the several files type which can be created for the Windows Installer technology like .msi, .msm, .cub, .mst, .idt and .pcp files.

.MSI -> .MSI file is Windows Installer installation package. It is a database file which is used to manage the various states of the application like adding, changing, or removing it from a computer.

.MSM -> .MSM is a Windows Installer Merge modules, which are pre-compiled libraries of components like files, registry, and other system changes that installs a discrete portion of the application.

Read this article to understand, how an Merge Module (.msm) works!

.MSP -> .MSP is a Windows Installer Patch file used to distribute small updates of .MSIs.To know more on Patches refer this article

.MST -> .MST is a Windows Installer transform file that makes changes to a pre-existing .MSI.  A transform encapsulates all the changes which can be made to a base msi and hence it enables to maintain a SINGLE installation FILE and changes separately in the TRANSFORM file. An Example, having a single MSi for Office product, Creating two different Transform files for different licenses. Thereby ensuring that, the same package can be used in 2 different divisions. This will also ensure that, the base msi package is never changed.

.IDT -> .IDT is an Exported Windows Installer database table which can be removed from one database and imported to another database. Using this, you can copy a table alone into a new MSI package.

.CUB -> .CUB is a Validation Module that contains Internal Consistency Evaluators in a database which in turn evaluates databases.

For more information on Package Validation .Cub files, check here

.PCP -> .PCP file is a Windows Installer patch creation file that contains the configuration information that patchwiz.dll requires to create a patch.

For Using Patch Creation Tool in Wise Package Studio, Read this!!

Categories
Windows Installer, Application Compatibility and Deployments

Redistributing Application Components using Merge Modules

Most developers understand the benefits of writing reusable code. It makes sense to use that piece again when you need the same functionality. The more pre-tested software you can reuse, the fewer bugs you’re likely to have in the final product.

Merge modules extend the notion of reusable components to the software installation process. Once you’ve developed a way to install a reusable component, you can also reuse the installation process!

mergemodulesMerge modules are pre-compiled libraries of components like files, registry, and other system changes which install a discrete portion of the application. This common module can be added to the various applications, instead of adding individual components to different msi files. They cannot be installed alone. they must be merged or added to an msi file to install it.

Merge modules are a mechanism that allows many Application Publishers to prepackage components, sign them and share these standard modules!

A merge module is similar in structure to a simplified Windows Installer .msi file. A merge module(msm file) contains files, DLLs, ActiveX components, registry entries and some system configurations like environment variables that make up these runtimes.

The use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files!

As mentioned before, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers can also create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.

Developers can use this method to merge modules or obtain a merge tool from an independent software vendor like Wise, InstallShield etc.

When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application’s .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user.

Merge modules is a tool for the developer, not for the end user!

Summing up, points to remember about the merge modules:

  1. All the information required to install a shared file is delivered to the installer in a single, standardized .msm file.
  2. Eliminate many instances of version clashing, missing registry entries, and improperly installed files.
  3. Traditional installers keep an incremental reference count of the number of applications using a shared file, but not the name of the application. If shared files are installed from .msm files, the Windows installer can keep a correct reference list of applications that use those shared files.
  4. Windows can better avoid deleting shared resources used by any application until the last application using them is uninstalled.
Categories
Guest Posts How-to Windows Installer, Application Compatibility and Deployments

Create a Minor Upgrade for an application using InstallShield

Upgrades are little complex compared to the new installer. This guest article from Bhuvana aims at providing the requirement for minor upgrade, the steps to create it and options to install the same. Minor upgrade is a type of Product upgrade that Windows Installer supports. A minor upgrade can be used to add new features and components but cannot reorganize the feature-component tree.

Requirement for Minor upgrade:

Add a new subfeature

If the new subfeature consists of new components only, you can use a minor upgrade. If the new subfeature consists of existing components, you must use a major upgrade.

Add a new component to a new feature

In general, a minor upgrade should not include a new top-level feature. However, new subfeatures of existing features are allowed. If you are adding a new subfeature for a minor upgrade, set two of the subfeature’s properties as follows so that they are installed correctly during a minor upgrade:
o    Remote Installation—Set this property to Favor Parent.
o    Required—Set this property to Yes.
The user interface of a minor upgrade does not usually show the feature tree; however, maintenance mode for the updated installation typically does expose the feature tree. If you want the new subfeature to be excluded from the feature tree so that end users cannot deselect it, set the subfeature’s Display property to Not Visible.

Add a new component to an existing feature

A new component can be added to an existing feature if the version of Windows Installer is 2.0 or later

Add, remove, or modify any of the following: files, registry keys, or shortcuts.

If the file, registry key, or shortcut is in more than one component and the component is shared by two or more features, a major upgrade must be used.

Codes Associated with the Minor Upgrade:

Package CodePart of the Summary Information Stream, the package code identifies a particular database. The package code is not a Windows Installer property. Any two .msi databases with identical package codes must have identical contents. So it is recommended to change the package code for each and a must for Minor Upgrade.

ProductVersion—This is a Windows Installer property that contains the product version. Note that Windows Installer uses only the first three fields of the ProductVersion property for version comparisons. For example, for a product version of 1.2.3.4, the 4 is ignored. (Note that this is true for comparisons of ProductVersion values, and not for file versions.)

Package code and Product Version needs to be changed for Minor Upgrade.

Steps to create Minor Upgrade:

  1. Change the Package code and Product Version to create a minor upgrade
  2. Add feature / component by following the guide lines in Section: Requirement for Minor upgrade
  3. Add Remove or Modify files, registry keys and shortcuts.
  4. Add minor upgrade item in upgrades view (this is optional).
  5. Build and use the installer for upgrade.

Running a Minor Upgrade:

With Setup.exe

If you build a release that includes Setup.exe, your latest installation will be minor upgrade enabled. Setup.exe can detect when a previous version of your application exists on a target machine. When Setup.exe detects a previous version, it will run the rest of your installation in minor upgrade mode.
If you have selected the option “Create installation launcher (setup.exe)” when you built the release and if you get an error as Figure1, while running the installer, then you will have to specify these parameters in the generated Setup.ini file:

[Startup]
CmdLine=REINSTALLMODE=vomus REINSTALL=ALL

Without Setup.exe

If you intend to distribute your installation without wrapping it in Setup.exe, there is a manual process that your end users must follow to start the installation. For this reason, you should consider using Setup.exe; however, you can achieve similar results without it. The Installer properties REINSTALL and REINSTALLMODE must be set from the command line to start an installation in upgrade mode. In all but the most advanced scenarios, the property REINSTALLMODE should be set to vomus and the property REINSTALL should be set to ALL. A typical command line can look like the following: msiexec.exe /i \product.msi REINSTALLMODE=voums REINSTALL=ALL

If the update contains features that you do not want to update, you should set REINSTALL to a comma-separated list of the features that you want to update, as in the following command: msiexec /i \product.msi REINSTALLMODE=voums REINSTALL=F1,F3,F5

The feature names you use in the REINSTALL property are case-sensitive.

If you try to install two msi packages with different package codes, but with the same product code, you will get an error message as shown in the below figure,
fig
To overwrite the existing product with a newer version, you should perform a small or minor update. This requires that you set the following properties on the msiexec command line: msiexec /i Yourapp.msi REINSTALLMODE=vomus REINSTALL=ALL

The important part is the “v” in the reinstall mode settings. It forces the use of the new msi file instead of the cached copy. Therefore it can’t be set inside the package. The rest of the REINSTALLMODE flags make sure that existing files get updated, new files get installed, registry entries are re-written and shortcuts are created. REINSTALL=ALL means that only those features, that were selected by the user during the install of the old version get updated. Unselected features should not be added.

Difference between Small and Minor update:
Small and minor updates are very similar. The only difference is that in a minor update the product version is increased (in any of the first thee fields), while a small update leaves the version number unchanged or increases only the fourth field of the number. You can update your product with a small or minor update package only if the product code is unchanged. To replace an existing application with a package that has a different product code, a major upgrade is required.

Bhuvana specializes in InstallShield & MSI Installers and her primary responsibility at work is “Build & Release” which includes creating Setups and Source Control Management. If you want to get in touch, her LinkedIn Profile is – Here. (PS: Do mention in the Linkedin request that, you read her article on msigeek. We do not want to give her un-necessary Spams )

Do comment on this article, if you have any inputs / suggestions for Minor upgrade!

Categories
How-to Microsoft Windows Installer, Application Compatibility and Deployments

Troubleshoot the error 1603 “Fatal Error During Installation”

This error message is displayed by the Microsoft Windows Installer Engine (Wondering whats this? Read here) and is a general error code that indicates a problem occurred during the installation. Read on this article to learn how to sidestep this speed bump. The following is the probable list of known causes for this error to occur:

  • Short file name creation is disabled on the target machine.
  • An Install Script custom action is prototyped incorrectly.
  • A file is locked and cannot be overwritten.
  • The Microsoft Windows Installer Service is not installed correctly.
  • The Windows Temp folders are full.
  • The setup was corrupted after installation and, therefore, fails with this error during un-installation.
  • An older version of Install Shield Developer is being used.
  • Print and File sharing is not installed if your application needs it.

Troubleshooting 1603 MSI Error

As discussed, The 1603 error code is mostly returned when any action fails during an installation on Windows, and most commonly it indicates that one of the custom actions in the MSI failed. When we encounter a failed setup with return code 1603, here are the steps that we should follow:

Re-run the setup with verbose logging enabled using steps similar to those that are listed here.

Step 1: Generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed. (Click here to know more ways to generate log). Know more about the command-line switches here.

msiexec /i <msipath>setup.msi /l*v c:\temp\msi.log

Step 2: Open the verbose log in a text editor such as notepad and search for the string “return value 3”. In nearly all cases, this will take us to the section in the verbose log that lists the action that failed that initially caused setup to rollback.

Step 3: Review the contents of the log file immediately above the “return value 3” string to determine which custom action or standard action failed. Depending on which action is failing, We will need to proceed to more detailed debugging from here.

One can find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for “return value 3” ends up helping speed this process up in nearly all cases. Of course, it does not work in 100% of scenarios.

You can find some ways of troubleshooting the logs here –
http://www.msigeek.com/261/identifying-installation-failure-through-cas-using-msi-logs
http://www.msigeek.com/257/interpreting-windows-installer-logs

“Access your favorite Windows Applications from your Android/iOS device with a virtual desktop by CloudDesktopOnline.com-one of the best Desktop as a Service providers. Get a free trial of Office 365 and excellent support by O365CloudExperts.com

Known Solutions

The following solutions have resolved this error in the majority of cases:

  1. Make sure short file name creation is enabled on the target machine. You can check to ensure that the target machine does not have short file name creation disabled by navigating to the following registry entry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

    Make sure the value “NtfsDisable8dot3NameCreation” is equal to 0. This indicates that short file name creation is enabled. A value of 1 indicates that this functionality is disabled. You should change the value to 0. After modifying this value, the target machine should be rebooted before attempting to launch the setup again.

    Note: If the target machine should normally have short file name creation disabled, it can be disabled after the install completes by resetting “NtfsDisable8dot3NameCreation” to 1 and rebooting.
  2. To ensure that the Windows Installer Service is properly installed and configured, it is recommended that users install the file InstmsiA.exe on Windows 95/98/Me or InstmsiW.exe on Win NT systems. These files are shipped with your InstallShield product and are located in the following location: <Product Path>\Redist\Language Independent\i386. If the service is installed, to know the status of the service exection, you could also goto services.msc in the command prompt, check the status of the Windows Installer Service. “Stopping and restarting it can help”
  3. Empty all temporary folders. The specific temporary folders for a machine can be determined by accessing the DOS prompt and typing set. Note the values listed for TEMP and TMP, and delete all files in those locations.
  4. Make sure no other applications, including utilities such as virus scanners, are running in the background. Close all running applications and utilities, and launch the installation again.
  5. If this error occurs during un-installation, use the Microsoft Windows Installer CleanUp utility to uninstall the installation. Once the installation has been successfully un-installed, you can then debug the project to determine what caused the original error.

If it doesn’t fall in this last, it could be any other error which occurred during the installation, do update in the comments..lets fix that..!

LinkedIn and other Discussions

I had also posted this on LinkedIn Discussions and have got some quality responses for the same – I will extract some information from there and post it here so that, you can get all the information at one single place.

A Senior Desktop Analyst, Jack Fei writes,

Vijay has makes some excellent points about how to troubleshoot these types of issues. From my experience, the fix is usually trivial once you understand “how to correlate verbose logging results” with msi internals.

First, know that “installation” means msiexec.exe sequentially processing rows of the InstallExecuteSequence table inside the msi database.

Second, know that msiexec.exe processes the commands sequenced between InstallInitialize and InstallFinalizes in two passes. A way to think about it is the first pass “conditionally installs the change” to the machine while checking the syntax of the command and the second pass “commits the change to the machine”. A 1603 essentially means “an error occurred” trying to commit the change, causing msiexec.exe to “backout the change”.

This type of error is either caused by msi misengineering (most vendor msi are misengineered) or by an “machine specfic issue”. So Patrick Pepin makes an excellent suggetion to check the msi vendor.

Having VMWare or imaging tool really helps troubleshoot this type of issue.

1. I would determine the issue can be reproduced on a clean machine with all pre-requisites installed (just to eliminate the possibility false negative caused by testing on an unknown or corrupt pc environment).

2. If it is a capture msi (original source is non-msi) I would systematically exclude files and registry keys until I isolated the component causing the issue in my msi. I built it, so I know best how to fix it.

3. if the msi was engineered by another vendor, I would review the verbose log and isolate the failing instruction in the InstallExecuteSequenceTable. My major technique was to find the failure that generated the “1603” error and find the likely instruction that caused it. To test my theory, I would comment out only that instruction (put a negative sign in the sequence column) and rerun the command. Sometimes, I would get lucky and even “work around” the msi defect by leaving the custom action commented out. This type of change works great when the custom action is doing “unnecessary checks” for desktops in your environments. Obviously, I would “test the modified msi” and make sure the application installed and starts cleanly.

4. If I can reproduce the problem on a clean desktop, I will have good ammunition to contact the vendor. However, my experience is if you know how to do what I have outlined, you will exhaust the technical support departments of whatever vendor you call. This is done for “political reasons” more than anything else – so you can be the hero when the vendor despite considerable persistance from you, can not find a solution.

Good luck. Hope this helps.

Categories
FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 4

instAs you guys are aware, I am writing a series of posts which covers some key discussions, topics and FAQs in the stream of MSI Windows Installer and application packaging. In this fourth part, we will look at some questions on MSI properties and key scenarios which can easily achieved by using the properties appropriately.

Q16. What are the types of properties and when do you use a Private property?

Properties are global variables that Windows Installer uses during an installation. As MSI is a database type structure, all the properties are saved in a table called PROPERTY table.  There are three types of properties.

PUBLIC: These properties can be changed by the Application packager in a transform / a system administrator can change it through the command line.  These are always in Capital Letters.  These properties are set during installation and it can be overridden in command line. Ex: INSTALLLEVEL, ALLUSERS, INSTALLDIR.

Properties that are set during the User interface dialogs should be public.

PRIVATE: These properties are used internally by the installer and their values must be entered into the database by the author of the installation package or set by the installer during the installation to values determined by the environment. For example, if the installation is run on a Windows platform, the installer sets the WindowsFolder property to the value specified in the Property table. These properties cannot be changed by the System administrator in command line and its always in lower cases. EX: WindowsFolder, SourceDir

RESTRICTED PUBLIC: There are certain conditions where SystemAdmin can exert control over the PUBLIC properties so that a user with an elevated privileges can’t modify or access them so as to maintain secure systems these properties are know as Restricted PUBLIC PROPERTIES. These properties has a limited set of values. For eg: ALLUSERS,REBOOT

The best practice is to set the ALLUSER property  =1 because if the application is to be installed to per machine and a user without admin access try to install that it will prompt an error but in the other cases it will be a peruser installation without any prompts.

Q17. What would you do, when you (do not) want your installer to restart the machine after installation?

The REBOOT property takes care of this.  The REBOOT property can have any of the below values.

REBOOT = Force – Always prompt for a computer restart at the end of the installation. The UI prompts the user to restart at the end. If there is no user interface, the system restarts at the end of the installation

REBOOT=Suppress – Suppress restart prompts at the end of the installation. During installation, Windows Installer prompts the user to restart whenever it encounters ForceReboot set by the application vendor

REBOOT=ReallySuppress – This will suppress all restart prompts that ForceReboot initiates during the installation and also suppress all restart prompts at the end of the installation.

Setting the REBOOTPROMPT property to Suppress (or S) allows Installer to perform a computer restart, if necessary, without prompting the user.

Q18. How can you disable/Hide an application from Add/Remove Programs?

Setting the ARPSYSTEMCOMPONENT property to 1 will hide the application from appearing. Also, ARPNOREMOVE property to 1, will just disable the remove button from Add/remove Programs.

Q19. When would you use REINSTALL property and what is its significance?

REINSTALL is an important property which is used while Application patching and Upgrades.  If you set the REINSTALL property, you must also set the REINSTALLMODE property, to indicate the type of reinstall you want.

When the REINSTALLMODE property is not set, all files currently installed are reinstalled, but only if the file on the computer is an earlier version or is not present. By default, no registry entries are rewritten if REINSTALL is set to ALL, only features already installed are reinstalled Thus, if REINSTALL is set for a product that is yet to be installed, no installation takes place.

 By default the REINSTALLMODE is “omus”.

For eg: Msiexec /p AdbeRdrUpd913_all_incr.msp REINSTALL=ALL REINSTALLMODE=omus

 p – Reinstalls a product only when a file is missing

  •  o – or an older version of a file is installed
  •  e – or an equal or older version of a file is installed
  •  d – or a different version of a file is installed
  •  c – or the stored checksum value doesn’t match the calculated value
  •  a – Forces all files to be reinstalled
  •  u – Rewrites all required user-specific registry entries
  •  m – Rewrites all required computer-specific registry entries
  •  s – Overwrites all existing shortcuts
  • v – This switch forces the installation to ignore the cached MSI package on the machine and recache the new package being run. This should only be used in an upgrade and not with a first-time installation.


Q20.  Which are the Properties that are mandatory for an MSI installation to work?

ProductCode; ProductLanguage; ProductVersion; ProductName;Manufacturer

For Information on ADDLOCAL property, check this article – http://www.msigeek.com/310/installing-specific-features-in-a-msi-package

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4, Part 5 (Coming Soon)

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

How do I install a Windows Installer Patch?

Consider a scenario where a single file in the application has undergone a change, and this file needs to be replaced in all the machines where it is Installed. In such a situation, it doesn’t make sense in creating a new package and deploy the same. Also, if we have any configuration file which the user has modified for his customization, re-installing the package will also replace those files. Hence, we will need to find a way to replace only that file.., without reinstalling the application package. That is where a patch comes into picture. 

Keeping it simple, a patch is basically the file from which changes to an already installed application is done. Also, a Patch can be installed individually, if the previous MSI already exists in the system. A windows Installer Patch file, will usually have an extension of .msp.
 
How to Install a Patch
 
When you run the patch Silent/unattended, the dialogs are not displayed and the required property like REINSTALL are not set. Hence, we will need to define this in the command line for Patch Installation.

Msiexec /p ABC10_v1.msp REINSTALL=ALL REINSTALLMODE=omus

Also, double-clicking the .MSP file will patch an existing installation as well as the locally cached copy of the MSI database because the dialogs are run and they in turn set REINSTALL and REINSTALLMODE properties.

Advantages of Using Patches:

  1. A patch can contain an entire file or only the file bits necessary to update part of the file. This will enable the user to download an upgrade patch that is much smaller than the installation package for the entire product.
  2. Create and install patches that can be uninstalled singly, and in any order, without having to uninstall and reinstall the entire application and other patches.
  3. Skip actions associated with specific tables that are unmodified by the patch. This can significantly reduce the time required to install the patch
  4. An update using a patch can preserve a user customization of the application through the upgrade.
Categories
How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

Creating your first WiX project

The Wix tools allow you to define the structure of a windows installer package using an XML file. This gives you all of the usual benefits of XML: easy editing with a variety of tools, the ability to modify the files using well-known technologies, and the ability to put the source file under source code control, for ex. the Wix tools themselves are command-line tools, so they fit well with almost any build process. In this post, we will look at creating a WiX project using Visual Studio.

A little note on MSi Engineering
Windows Installer setup package can be described as a three-level hierarchy. The product is at the top of that hierarchy. Users can interact with a Windows Installer setup package at the product level, as during a default or typical install, or they might interact with the setup package at the features level, as during a custom install. Developers, on the other hand, have to interact with the setup package at the component and individual resource level.

Packages are built from components. A component is a group of one or more related resources—files, shortcuts, registry entries, etc.

Components are grouped into features. A feature is a group of one or more components that are installed together. A component can belong to one or more features, but each component is installed only once on a give machine.

Every Windows Installer product, package, and component is identified internally by a unique GUID. The product code GUID remains constant for all releases within the same major version of a product. The package code GUID changes for each build that is released into the wild. The component code GUID changes according to the rules governing components.

For more information on Component Rules Click Here

Starting a WiX project in Visual Studio

Step 1: Launch Visual Studio, and create a new project.

Step 2: Select Setup Project, Windows Installer XML Section

Step 3: Your first Wix Script and template is ready, you will get intuitive help when you start typing – Thanks to Votive

Explaining WiX script Elements

The product element defines the product that the installer will install. The name of the element corresponds to a table in the windows installer database, and the attributes correspond to the columns in the table. For instance, the installer database includes foreign key columns to relates many tables, while the WiX source files use nesting to accomplish the same relation. The WiX tools take care of defining the appropriate foreign key values for you.

–Package Id=”6697CCC3-B351-4DCE-820E-DEAC87F57A2A” Comments=”Demo Installer” Manufacturer=”Msigeek.com” InstallerVersion=”200″ Languages=”1033″ Compressed=”yes”

Within the product element, you’ll find a single package element, defining the package that corresponds to this WiX file.

–Media Id=”1″ EmbedCab=”yes” Cabinet=”test.cab”

The media element defines the distribution media where the MSI file and any associated CAB files will be stored.

The directory elements define the hierarchy of directories that the installer service will use with this software. Note that the Id attributes are not completely arbitrary. The windows installer defines a number of special directories, including the two (the program files folder and the program menu folder) that I’m using in this example.

The Component elements and their child elements define the exact software that will be installed. In this case, the first component consists of a single file, while the second includes a file and a shortcut to the file. Note that WiX will look for the files that you include relative to the XML file. The best plan is probably to place the XML file in the same folder as your source files, and place the wix tools on your path.

The feature element defines both the single feature in this package and the mapping between features and components.

One will need both the Windows Installer SDK and the WiX documentation to develop Wix Scripts and MSis.

Categories
Microsoft Tools Windows Installer, Application Compatibility and Deployments

WiX v3.0 now available for download

The final build of WiX v3.0 is 3.0.5419 has been released to SourceForge and marked RTM/stable. You can download it from http://sourceforge.net/projects/wix/files/.

Also, Votive is now available for Visual Studio 2010 beta. I would suggest all Visual Studio 2010 Beta users to upgrade to the latest build of WiX v3.5 to try out the feature. You can download it from http://wix.sourceforge.net/releases/3.5.0605.0/.
You also get,
A new set of detection properties for .NET Framework 4 beta installation states in the WixNetfxExtension
A new set of detection properties and registration custom actions for Visual Studio 2010 beta editions in the WixVsExtension.

Call to Actions
Votive – http://wix.sourceforge.net/votive.html
WiX v3.0 online documentation – http://wix.sourceforge.net/manual-wix3/main.htm
Rob Mensching’s announcement about the release of the final version of WiX v3.0 – http://robmensching.com/blog/posts/2009/7/4/WiX-v3.0-released
Tips to migrate from wix v2 to wix v3http://robmensching.com/blog/posts/2009/7/7/Tips-on-how-to-upgrade-from-WiX-v2-to-WiX-v3
Bob Arnson’s announcement – http://www.joyofsetup.com/2009/07/04/wix-v3-0-has-been-released/
WiX site on SourceForgehttp://wix.sourceforge.net
WiX tutorialhttp://wix.sourceforge.net/tutorial.html
Clickthroughhttp://wix.sourceforge.net/clickthrough.html

Folks, who aren’t aware about WiX….
The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset provides a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages.

WiX is an open source project, originally developed by Microsoft and maintained by Rob Mensching. You can download the latest binary and source code releases from SourceForge. This tutorial originally describes version 2.0, the stable release. Version 3 is still under development and although it is still a moving target, we have started to add material that describes the changes brought about by the new version.

The toolset is written in C# and requires the .NET Framework 1.1 and its Service Pack 1 to run. However, this only applies to the toolset itself. The installation packages you create with the toolset do not require any extra framework or software to be installed on the target computer. Similarly, there might be a few additional utilities required for some special applications (merge modules, patches) but only on your build computer, the client will only need the finished and self-contained installer package, nothing else.

Join WiX Group:
There is a friendly community of Wix developers and users in a dedicated mailing list, hosted at SourceForge. This is the best place to ask for advice about any aspect of WiX. If you already have a SourceForge account, you can join on the website, too, but the simplest way is to send an empty message to the subscription address.