This is the second part of my series on creating a setup program for Shared .NET Add-Ins for Office 2007 (read Part 1). One of the toughest problems is figuring out what you should ship with your setup program besides your actual add-in. To ensure that your Shared .NET Office 2007 Add-In will work under any circumstance, you will need to include the following:

• Windows Installer 3.1. Installed by the setup bootstrapper (setup.exe). You generally don’t include this in your actual setup package, but rather let the setup bootstrapper download it as needed from Microsoft.
• .NET Framework 2. This is installed by the setup bootstrapper as well and should be downloaded as needed from Microsoft directly. Including the .NET Framework 2 in your package would increase the size of your downloadable file way too much.
• Visual C++ 8 runtime DLLs. If you use the COM shim wizard, then you should ship the VC++ 8 runtime DLLs with your add-in. There are multiple ways you could redistribute these files: You could include the Visual C++ Redistributable Package in your setup bootstrapper. Or you could use a merge module and include the files directly into your MSI. Unfortunately both these approaches require administrative privileges in Vista, and hence cannot be used for our standard-user installable setup program. Thankfully there is a third method, which simply requires you to include a number of DLLs into your MSI and copy them to your application folder: Include the entire Microsoft.VC80.CRT folder found in %programfiles%\Microsoft Visual Studio 8\VC\redist\x86 into your MSI and make sure that its files get installed in a similar named subdirectory of your application folder.
• Office 2007 Primary Interop Assemblies (PIAs). The Office 2007 PIAs allow your .NET add-in to interact with Office 2007. They are absolutely needed. Office 2007 will install them as part of a typical install, if the .NET 2 Framework is present during the Office setup. As this might not be always the case, you have to ship them with your add-in. Again, you could install them via their redistributable package as part of your setup bootstrapper. Unfortunately again, this requires administrative privileges. Therefore you have no other choice but to include the individual DLLs in your MSI. You have to make sure that they are not registered in the Global Assembly Cache (GAC), because a GAC registration requires administrative privileges. You need to include the following files:
  • extensibility.dll. IDTExtensibility2 interface, which your add-in uses to plug itself into Office.
  • stdole.dll. OLE Automation support.
  • Microsoft.Vbe.Interop.dll. Microsoft Visual Basic for Applications Extensibility 5.3. Needed due to dependency reasons of the Office object model.
  • office.dll. This is the Microsoft Office 12.0 Object Library. In the references of a Visual Studio project and in the Object browser, you can find this one as Microsoft.Office.Core.
  • Microsoft.Office.Interop.XXXXXXXX.dll. Each application has its own PIA DLL. You need to include the PIA for every application your add-in supports. For example, an add-in supporting Excel, PPT and Word needs to include Microsoft.Office.Interop.Excel.dll, Microsoft.Office.Interop.PowerPoint.dll and Microsoft.Office.Interop.Word.dll. See this MSDN article for a full list of available PIAs for Office 2007.
• Last, but not least, your MSI needs to include your Shim DLL, your .NET DLL and all supporting DLLs, e.g. for .NET components. Again, do not register anything in the GAC.

Let me conclude with a word about KB 908002. KB 908002 is not required for Office 2007 despite the KB stating differently at this point in time. KB 908002 includes three different components, one of which is extensibility.dll. Due to that, the KB will appear to fix a runtime crash of a shared .NET add-in in situations where the .NET Framework 2 was installed after Office 2007. However, you can achieve the same fixing effect by simply including extensibility.dll in your MSI as outlined above. That the KB incorrectly lists Office 2007 as applicable program is my fault, as I asked Microsoft to add this when I observed the fixing effect it had and before I tried to build my own setup program via WiX. Microsoft is currently investigating how to best include the real situation into the KB.