Compartir a través de

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

  • Artículo

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.

Comments

  • Anonymous
    July 12, 2006
    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
  • Anonymous
    July 13, 2006
    The comment has been removed
  • Anonymous
    July 13, 2006
    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.
  • Anonymous
    July 27, 2006
    PingBack from http://blogs.msdn.com/robmen/archive/2006/07/27/681261.aspx
  • Anonymous
    August 16, 2006
    The comment has been removed