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:

  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.

Comments (5)

  1. Jordi says:

    What an utter dissapointment this blog post is! Instead of stating the obvious – Office XP PIA redistribution is awful, but you can create a MSI file yourself, why not dig up the source code and show us exactly how you did it? Now that would be helpful.

    — Jordi

  2. Kalle Olavi Niemitalo says:

    I assume you had to generate your own Windows Installer component codes for the Office PIAs.  Now if another team also includes the assemblies in a MSI package and generates different component codes, will there be problems when the components are installed in the same computer?  If so, is Microsoft going to publish MSMs to make it easy to use your GUIDs?

  3. Hey Bob – Minor point here, but gacutil.exe did not ship with all versions of the .NET Framework 1.1 runtime.  It is only included with the version of the .NET Framework 1.1 runtime that is included as a part of the OS on Windows Server 2003.  It is not a part of the MSI-based package.  In addition, the only reason it was included in Windows Server 2003 was because we needed to use it to install the .NET Framework assemblies to the GAC during OS setup.

  4. anonynous says:

    are you kidding? WHATEVER HAPPENED TO FASTER, BETTER AND MORE SIMPLE? i got into this business 20+ years ago to help others and now…. IT IS GONE BEYOND PRACTICAL.

    all the junk you see here… complicated madness!