I’ve got a VSTO Com Addin for Word that I’m building an installation for. In the past, the addin had been handled via a DOT file, which is effective, but isn’t really the best way to build addins for Word, especially not now with VSTO.

At any rate, the product is working great, so I was putting an installation together.

I marked the particular assembly as .NET Interop, and when I built, IS complained that it couldn’t get the interop info from the assembly.

Huh? After some digging, turns out that InstallShield runs REGASM.EXE with the /REGFILE: switch to extract the COM registry information from the assembly, and then saves that in the MSI.

So, I tried running REGASM on my dev machine with the assembly.

REGASM MyName.MyAsm.dll /REGFILE:TestFile.reg

Worked perfectly.

So I tried it on my IS2009 box with the same assembly.

RegAsm : error RA0000 : Could not load file or assembly ‘Extensibility, Version=
7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its depe
ndencies. The system cannot find the file specified.

Hrm?

After scratching my head for a bit, I realized that my assemblies were compiled with .NET Framework 3.5, and that they definitely use some of the 3.5 specific features. It’d make sense that not having .NET 3.5 on the IS box could cause this.

So, a painstakingly lengthy .NET 3.5 install later, and I try the same regasm on my IS box.

No joy. Grrr.

So, I do what I should have done in the first place, open the project in Visual Studio and check the references. Sure enough, it points to an Extensibility.dll from the VSTO installation. Duh.

So, I go and install VSTO (to the InstallShield box, another grrr…)

No problems there, but still no joy.

Another look in the project and this Extensibility.dll lives with the VSTO V9.0 stuff. If I’m not mistaken, that means it’s an Office 2007 thing, not 2003 (which just happens to be the version of Office on the IS box).

Ok, maybe if I install the Office 2007 Primary Interop Assemblies?

More Grrr…

At this point, things are just irritating. I don’t want to install Office 2007 on what should ideally remain a more or less pristine dev box for doing install builds, so what next.

I know where this Extensibility.dll lives on my dev machine, I’m just not sure how REGASM looks for it, the GAC maybe, a search path (not likely), or some other arcana?

Screw it, I grab a copy of Extensibility.dll off my dev machine and copy it to the same folder as the DLL I’m trying to run regasm on.

RegAsm : error RA0000 : Could not load file or assembly ‘Microsoft.VisualStudio.
Tools.Applications.Runtime.v9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToke
n=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file
specified.

Aha! Similar message, different DLL! Now we’re getting somewhere.

Grab a copy of this “‘Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll” file off my dev machine, copy it to the same place and regasm again.

Repeat for another two dlls and REGASM will finally run through with no errors.

I’ve already had to pull TLBs and OLBs from Office installs for reference purposes in the application (for use on some dev boxes that don’t have either Office 2003 or 2007 installed), so grabbing a few more dlls for referencing purposes isn’t a big deal; they don’t have to be shipped with the application (they come with either VSTO or Office itself), and they can be checked into version control just like anything else.

In the end, I’m still not entirely convinced VSTO is a good way to build commercial addins for Office applications. It’s fine for quick and dirty internal projects, but it just seems to add a lot of additional complexity to releasing a commercial app. It’s harder to build a non-VSTO addin, but the end results may justify the extra effort.

Your mileage may vary.