Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
The MSIs for the XNA Game Studio Express 1.0 and 1.0 Refresh releases were created using WiX v2.0. The MSIs for the recently released XNA Game Studio 2.0 product were created with a recent build of WiX v3.0. The decision to move from WiX v2.0 to v3.0 is interesting so I wanted to describe how this decision came about behind the scenes.
XNA Game Studio Express 1.0 and 1.0 Refresh integrate into Visual C# 2005 Express Edition only. As noted in this introductory blog post, XNA Game Studio 2.0 now integrates into Visual Studio 2005 standard edition and higher in addition to Visual C# 2005 Express Edition.
XNA Game Studio 2.0 ships a Visual Studio starter kit for a game named Spacewar. This starter kit takes the form of a .zip file for the Windows version of the game and a .zip file for the Xbox 360 version of the game. Each of these .zip files is approximately 30 megabytes in size, and they must be installed to separate locations in order to integrate correctly into Visual C# 2005 Express Edition and the up-level editions of Visual Studio 2005.
In order to minimize the size of the payload for XNA Game Studio 2.0, we needed to find a solution that would allow us to carry only one source copy of each .zip file, but install each .zip file to multiple locations on the system. In addition, we decided to continue to use embedded cab files inside of each MSI we create to deliver the setup payload.
We could have used the DuplicateFile table, but there are some potential limitations with using this table that are related to conditional installs, repairs and patching, so we decided to not use it in XNA Game Studio 2.0 setup if we could avoid it.
Fortunately, WiX v3.0 introduced a new feature last year known as smart cabbing. This feature allows the WiX build process to embed a single physical copy of each file in the cab files it creates if the file is referenced by multiple File elements. The WiX toolset will apply this feature automatically (and not require any setup authoring changes for the feature to take effect) if you author your setup to include multiple files with the same source location defined for them.
By switching to WiX v3.0 and gaining access to the smart cabbing feature, we were able to eliminate 60 megabytes of payload from the XNA Game Studio 2.0 setup package without adding any new setup authoring. This resulted in an overall packages size of approximately 100 megabytes as opposed to 160 megabytes - a size reduction of 37.5%!
PingBack from http://geeklectures.info/2008/01/07/why-xna-game-studio-20-setup-switched-from-using-wix-v20-to-using-wix-v30/
PingBack from http://msdnrss.thecoderblogs.com/2008/01/07/why-xna-game-studio-20-setup-switched-from-using-wix-v20-to-using-wix-v30/
It's interesting that you didn't mention WiX 3.0 is a beta toolset.
Hi Christopher - Correct, the WiX site on SourceForge lists that WiX v3.0 is a beta. There are still bugs being fixed and some features being worked on (such as patching support, some extension work, etc). However, a large majority of the WiX v3.0 toolset is stable, and several Microsoft products have built and shipped using it, including the Visual Studio 2008 family of products. What I generally encourage folks to do is try out WiX v3.0 for their setup build scenarios, and advise that they may need to report bugs or pick up newer builds of WiX v3.0 if they run into any blocking issues. We didn't run into any such issues with the XNA Game Studio 2.0 product though, so it should be possible to use WiX v3.0 in production scenarios in many cases.
As noted in the Highlights of WiX v3.0.4311.0 post on Bob Arnson's blog , Neil Enns recently contributed