Do i have to force my customers to install the Office Xxxx Primary Interop Assemblies?

Question

It seems if you try to reference the Office COM objects (as you would do in other development environments), Visual Studio gets it wrong - and it just won't work.

So you must use the converted type library that Microsoft hand-converted and makes available for download, and download, and download.

Now it seems that in order for my application to run it needs the Office Interop code, which is contained in an assembly.

Now i don't want to force my customers to install the Office 2007 Primary Interop Assemblies, Office 2003 Primary Interop Assemblies or the Office XP Primary Interop Assemblies. i want an xcopy deployment.

If i manage to get a hold of Microsoft's copy of the interop assemblies, can i just copy them to by Bin/Debug and Bin/Release folders?

If i include the Office 2007 interop assemblies, will it work if the customer has Office 95 installed, or do i have to include all versions of the Office Interop dll's Microsoft has ever published?

Answer 1

This is a common question with a rather complicated answer. Mary Lee of MSFT is a great resource for information about this:

http://blogs.msdn.com/vsto/archive/tags/Deployment/default.aspx

Using ClickOnce to deploy is the closest you are going to get to an XCopy install of any application built on VSTO.

Also, check this post:

http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/

Finally, Misha has a great blog:

http://blogs.msdn.com/mshneer/archive/2006/01/05/deployment-articles.aspx

The PIAs are specific to the version of Office you are targeting, so the 2003 PIAs are necessary for targeting 2003 and the 2007 PIAs are necessary for 2007. Automating Office 95 via managed code is something I have not done before, but I can imagine you are directly referencing the type libraries so a RCW is generated for you and has nothing to do with PIAs.

HTH

Colby Africa (MSFT)

Answer 2

From my own experience:

If you wanted to target Office 2003 and above, then you'd use the Office 2003 PIAs - and limit yourself to the Office 2003 API. The code would run on Office 2003 or later. You could still call Office 2007 functions using reflection, but that's not pleasant.

I imagine it's much the same story if your baseline version is Office 2000 - though I've not tried it, and I believe the earliest version for which Microsoft themselves provide PIAs is Office 2002 (XP).

You can create your own Interop assemblies for 2000, and I've no reason to believe that you can't do it for '95, though you're the first person I've ever seen ask for '95 support! It goes without saying that if you create your own Interop assemblies you'll need to deploy them with your application.

In any case, you want to use the highest Office version you can get away with as your baseline, so that you can support as many features as you can without resorting to reflection. You should develop your code on a machine which has only that version of Office installed.

In my case, I develop for Office 2003 and know that my users also have 2003. So, I ask them to ensure that they have the ".NET Programmability Support" feature enabled (which you can do via Office 2003 Setup via Add/Remove Programs if you choose the Change option). That option basically installs the PIAs to the GAC. For those users that can't do this, my setup program detects the lack of the PIAs and installs them prior to installing my application (as it does for the .NET framework).

XCOPY deployment? Yes, I'd like that too - but forget it. For one thing, if your add-in is going to work in 'high' security mode, then you're going to need a code-signed COM 'shim' to sit between your code and Office, and that needs to be registered. I believe VSTO provides its own shim, if you choose to go down that path (I didn't, since I needed to be able to 'drive' Office from scratch rather than relying on the user to start the application).

Deployment - and dealing with the installation & security issues - is one of the hardest parts of Office Add-in development with .NET, and it's a real kicker that it comes right at the end when you thought you were done.

My strong advice is to save yourself days and weeks of hassle, and look at Add-in Express. I've only recently come across this myself, and have been kicking myself ever since because it could have saved me so much time. It has several benefits that I think would be useful to you:

1. It allows you to create a single add-in targetting Office 2000 to Office 2007 (sorry, not '95), regardless of what version you happen to have on your development PC.
2. It creates an installer for you (which even works on Vista!), which in itself is worth the price.
3. It comes with its own COM shim, and is integrated to the extent that you don't need to worry about it.
4. It will allow you to have a single add-in that has a menu/toolbar interface in Office versions up to 2003, but a ribbon interface in 2007.

Note that I have no affiliation with Add-in Express (other than as a recent customer), but equally I've not yet converted my projects over to using it. The initial tests that I have done lead me to believe it's pretty good - and definitely the way to go for small to medium projects.