0

Several years ago, I did some pretty serious Office add-in development for Office 2003 (Word, Excel and PowerPoint). I created some shared COM add-ins in C# using Visual Studio 2003. At the time, I looked at VSTO, but decided for reasons that I can't fully remember that it was not suitable for my needs.

My add-ins are due for an upgrade now, and no longer need to support Office 2003 - though they do still need to support Office 2007, not just 2010.

I know that things have moved on significantly, and that Visual Studio 2010 has better support for Office development. I'd like to determine whether I should re-implement my add-ins using VSTO, or continue with the shared COM add-in route.

If anyone knows of a nice summary of the pros and cons of each approach (beyond the marketing hype), I'd love to hear it.

Things that I found very frustrating first time around (not using VSTO, but may apply anyway):

  • the need to manage COM references explicitly (and call ReleaseComObject everywhere)
  • the need for a COM shim to get the security model to work
  • visual studio installation projects just plain didn't work; I ended up building my own MSI-based installer
  • lack of documentation, particularly on all of the above; I spent weeks of trial-and-error and searching random blogs; the MS-supplied example code completely ignored all of these real-world issues

It's also worth mentioning that minimising the amount of stuff that needs to be installed prior to my add-ins is important. I think that one of the things that put me off VSTO was the need to deploy additional stuff (though since I never went down that route I don't know if that concern was justified). And I'd really like to be able to deploy on a standard Windows 7 (or Vista) build without the need to first install (say) .NET 4.

Gary McGill
  • 26,400
  • 25
  • 118
  • 202

1 Answers1

1

Partial answer but too long to fit in a comment:

Parts I can comment on:

  • Setup projects for VSTO addins now do actually work and there is a very good walkthrough available on how to create them properly.
  • Documentation in general of the office object model is poor imho and that should be equally annoying for com and c# development. Because a lot of the objects are now returned as dynamics if you use .net framework v4 you loose intellisense which does not help. The workaround for that is to be explicit in casting to known types where possible.
  • In order to run it obviously needs the relevant framework installed (v4 is FAR better for this than earlier version because of dynamics, optional arguments that were added under pressure from the office group and the NoPIA setting) Besides that it also needs the VSTO runtime installed.
  • All of these dependencies could be incorporated into the installer but they are required

You haven't specified what you used to create those com addins (My guess is c++ or vb6) and I can't tell how large they are and how much overhaul they need so it's not really possible to give advice if now is the time to make the change. One of the areas where moving to c# will certainly be far cleaner and nicer is anything related to ribbons. But again I can't estimate how relevant that is for you.

Eddy
  • 5,320
  • 24
  • 40
  • Thanks. (I did mention that I used C# last time around). The one major thing you've not touched on is the explicit management of COM references (ReleaseComObject etc.). Still necessary? I assume so - I don't think that's a problem that can ever go away regardless of the language / tools. – Gary McGill Aug 18 '11 at 07:10