Recently I was asked to explain the workflow for Industrial Strenth Windows Installer XML (IsWiX). In a nutshell IsWiX is all about enabling collaboration by enlisting the help of various contributors in defining the contents of the installer. This is done through the use of Microsoft Merge Modules. We use MSM's rather then fragments and libraries because the intent is to interop with other tools such as InstallShield 2011.
At my day job, Visual Studio is included in the standard developer image which pretty much everyone in Engineering gets. Recently I was doing some work for a client when it became clear that the person who could best contribute to the project wasn't a developer and didn't have Visual Studio. While VS is not strictly required by IsWiX it really does help. So I started looking for a solution to the problem of a non-developer persona contributing to Setup and I came across the following:
Microsoft offers a free, redistributable download:
Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package ( Installs .NET 4.0 )
This installer basically gives you a stripped down Visual Studio IDE with most tools and languages missing. It just happens that
Windows Installer XML 3.5 supports this shell. ( As an aside, WiX 3.0 supports the 2008 version of the shell. ) Finally,
IsWiX (Requires .NET 3.5 SP1) also supports this shell. So after downloading these three/four packages on an XP SP3 image we suddenly have a fully functioning IDE for authoring merge modules.
Now let's go through the workflow.
1) Start Visual Studio 2010
2) Select File | New Project
3) Select Merge Module Project and pick a location and project name followed by OK.
4) After the project is created and shown in solution explorer, rename the MergeModule.wxs to the "[project].wxs". (It'll work if you don't know this but it really gets annoying having dozens of wxs files with the same name.
5) Remove the TODO Create Component comments and save the WXS file.
At this point we are really just doing standard WiX stuff. Now let's go play with IsWiX.
6) Select Tools | IsWiXAddIn ( The one with the cheesy looking smiley face. )
The first screen to come up in IsWiX is the General Information designer. This is where we can view and edit information related to the ModuleSignature and ModuleDependency tables. ( Wix, Package and Dependency elements in WiX speak. )
7) Click on the Files and Folders Designer
The files and folders designer is where you can define the say which source files get installed where. In WiX this will be your Directory, Component and File Elements. If you look closely you'll see it's only letting you pick files from where the wixproj and wxs files are. This is because by default the designer orientates itself to the current directory. Let's change it to C:\
8) Click on the Code View Tab
Notice that IsWiX has authored a special preprocessor variable called SourceDir and assigned it a value of '.'. Let's change that line to read .... SourceDir="..\..\.." ( the number of ..'s will depend on where you put your wxs file or you can just point it to some other directory if you'd like. ) Now let's go watch the effect:
9) Click on the Designer View tab
Note the source files view now points to C:\. Let's author some files and folders into our merge module.
10) Drag a folder from the Source Files directory tree to the MergeRedirectFolder node on the destination folders tree.
Now we can see the directories / subdirectories and files shown in the destination. Let's send these changes back to visual studio.
11) Click the save button and close IsWiX.
At this point Visual Studio will notice that the contents of our wxs file has changed and ask if you want to reload it.
12) Click Yes
From here we can see the XML that IsWiX authored for us. We can now rebuild the project to verify that the module builds.
13) Right click the merge module project in the solution view and select Rebuild.
By now it should be obvious that IsWiX can allow non-developers to author merge modules. But WiX developers can also edit the raw XML by hand and add in additional elements such as ServiceInstall, ServiceControl, ShortCut, ProgId and so on. Most edits by hand will have no effect on IsWiX. Eventually it's hoped to write additional designers that can automate all of these elements.
The other point I'd like to make is the workflow that I use this with
1) Meet with subject area experts ( Dev, Web, Docs, DBAs et al ) and have a dialog where we provide them a basic understanding of Installers and they provide us a basic understanding of the design of their solutions.
2) Come to an agreement on how their solution breaks down into Feature and Merge Modules. Implement the feature tree in the installation tool of your choice ( InstallShield 2011 for me ) and do the initial setup of the merge module solution.
3) Inform the developers that it's now their job to keep the modules up to date and that we are available to assist / answer question and do additional meta markup such as services and COM.
So there it is in a nutshell. How I do collaboration using IsWiX / WiX and InstallShield. If your needs are limited you could use WiX or InstallShield 2010 Limited Edition and have a complete system with nothing but free tools.
Any questions?
PS- Just for fun I decided to try to install InstallShield 2010LE on the Visual Studio 2010 Shell. It kind of worked. It did install and I could open an existing ISL project but the ability to create a new LE project from the File menu was missing. This isn't important to the Collaboration discussion I mentioned above because I would expect the Setup developer supporting all of this would either have WiX, InstallShield Profesional or Visual Studio and InstallShield LE.
