Wix is a set of open source tools that compiles XML into Windows Installer based installers (.MSI), patch files (.MSP), transform files (.MST), and merge modules (.MSM). Wix is not a replacement for Windows Installer.
This site is for Wix version 3 information.
The SourceForge Wix Home Page and SourceForge Project Details contains a wealth of information and can't be beat for actual details. The following RSS feeds are provided via SourceForge (list of all available feeds):
Currently with Wix v2 or v3 there isn't "built in" support for deploying .NET. This often requested feature however can be easily accomplished using MSBuild, either from the command line or by modifying a Votive project file. Full details can be found under Deploying Additional Components.
The XML schemas define what elements may or may not be present in a .WXS file. Essentially the elements make up the "wix programming language".
The primary schema is the Wix Schema and the Wix Preprocessor. This schema contains a large number of elements, and covers pretty much all of the Windows Installer standard functionality. The preprocessor elements are not strictly speaking part of the XML schema, they operate in a manner similar to a C or C++ compiler's #include statement, including condition statements and so forth.
Wix also provides a framework for extensions. Extensions add new functionality through custom actions and new schema elements. The following extensions define custom schema elements:
Custom actions are very important to all but the simplest installation. There are a variety of custom action types, and they are all configured with the CustomAction Element. The Guide to CustomActions provides simple examples for each type of custom action.
The choice of VBScript for custom actions can be controversial.
Using VBScript may reduce the reliability of an installation package. For VBScript CA's to be effective, the VBScript runtime environment itself must be reliable, ie. if VBScript itself fails to run then an installation that relies on VBScript CA's fails miserably.
In situations where reliability is critical, the removal of an entire dependency, like VBScript, can reduce the overall error rate (fewer "moving parts" means less things to go wrong). This is especially true for large deployments like Microsoft Office and Microsoft Visual Studio (the Office team bans VBScript custom actions, and the Microsoft Visual Studio team's first MSI setup ran into problems with VBScript).
However, VBScript can also be very effective, especially for smaller deployments or tightly controlled deployments. VBScript is also very easy to write, easy to debug and easy to support. The VBScript Tutorial provides some concrete advice on how to best take advantage of VBScript and a couple of samples.
Here is a handy VS2005 macro to insert a new GUID.
Nothing like a straight-forward sample! All the samples are Visual Studio 2005 projects and make extensive use of Votive. Simply open the .SLN with Visual Studio 2005, build the solution, and run the resulting .MSI (typically located in the bin\Debug directory). Note the samples depends upon Wix being installed at C:\Program Files\Windows Installer XML v3. This can be adjusted by using Notepad to editing the *.wixproj file. Switch to $(ProgramFiles)\Windows Installer XML v3\ if you have installed v3 on a different root drive.
UiExtension (user interfaces)
NetFxExtension (detecting .NET, compiling to native code)
SqlExtension (creating/updating SQL Server databases)
Deploying Additional Components (.NET, SQL Express, etc)
Simple Custom Action Dll (C++ DLL custom action)