Creative Commons Add-in for Microsoft Office: Behind the Office PIAs.

Creative Commons Add-in for Microsoft OfficeTonight, we'll continue with the story of the development of the Creative Commons Add-in for Microsoft Office. As I mentioned in the introduction one of the first problems that we tackled was the Office PIAs. Rather than provide you second hand information about the development of the PIA packages, I've invited Bob Arnson to be a guest writer and tell you the story himself. So, without further ado, I present the "Rolling Your Own Redist" by Bob Arnson.


When a few members of the WiX team took on the side project of building the setup for the Creative Common Add-in, we had a set of requirements like most any software project. One of the requirements was that the add-in must support both Office XP and Office 2003.

As Rob mentioned, to support both versions of Office meant dealing with both sets of primary interop assemblies (PIAs). For Office 2003, that's fairly straightforward. Though Office Setup doesn't install the PIAs by default, Microsoft provided the Office 2003 PIAs as a redistributable MSI package.

For Office XP, the situation was a little less pleasant. The Office XP PIAs came as a set of DLLs, .reg files, and a batch file that calls Gacutil to install the assemblies into the .NET global assembly cache (GAC) and Regedit to write registry entries from the .reg files. Gacutil is a development tool, though it shipped in the .NET 1.1 Framework runtime. (In .NET 2.0, it's only in the SDK.) The Gacutil documentation even warns against its use as an installation tool:

Be aware that using the /i and /u options alone does not support reference counting. These options are appropriate for use during product development but not for actual product installations.

In fact, the batch file contains the following comment:

Note: This utility must be run from the Visual Studio .NET Command Prompt. It will not function properly otherwise.

And a batch file that calls Regedit? Well, you can read Rob's opinion on script custom actions and imagine how that might translate to using batch files during a real product setup.

So I signed up to create a good setup package for the Office XP PIAs. The batch file told me what I needed to do -- install the assemblies into the GAC and write some registry entries. Windows Installer natively supports both actions.

So one Tuesday night, instead of working on WiX, I put together a "first draft" of the Office XP PIA installer. Installing assemblies into the GAC is easy: Just add Assembly=".net" to the assembly's File element. For example:

 
<File 
  Id="MoiFrontPage.dll" 
 Name="Microsoft.Office.Interop.FrontPage.dll" 
  KeyPath="yes" 
  Assembly=".net" 
  DiskId="1" 
  Source="Microsoft.Office.Interop.FrontPage.dll" />

Converting the .reg files to WiX source code was also easy thanks to the WiX Tallow tool. I took the fragments Tallow created and pasted each one into the same component that held the assembly.

A few tests later, I was confident we had a decent installer for the Office XP PIAs. The job wasn't quite done -- Rob later added ComponentSearch, RegistrySearch, and FileSearch elements to prevent the PIAs from being reinstalled if they're already present. But none of it required any secret information from inside the Microsoft firewall. Best of all, there are no custom actions or batch files.