I’ve noticed an interesting pattern in the VSTO Forum on MSDN. Cindy Meister (the queen of VSTO & Word programing) will very often ask a poster whether they’re developing a Shared Add-in or a VSTO Add-in. Nearly all the responses to such questions indicate that the poster has no idea, and I can’t blame them. It seems that even if someone’s used the VSTO solution templates to create a new project targeted at Office applications, they could still end up inadvertently creating a Shared (or COM) add-in.
I finally got frustrated enough at trying to judge whether a question I’d ask would be “worthy” of the VSTO Forum, or would just be punted back to me to find an appropriate newsgroup — so I decided to figure out what’s the point of this once and for all.
I quickly discovered that Cindy has gotten this question in the past, and has summarized some of the differences here:
However, that still doesn’t answer the question of “Why should it matter whether my VSTO project actually turns out to be merely a Shared Add-in?”
- Does it change the way that you’d use certain .NET classes — or does it limit the kinds of classes that can be used by a Shared Add-in?
- Does it create incompatibilities on the deployed client — or does it require a different deployment approach for a Shared Add-in?
- Do certain data types, methods for creating Event Handlers, or Office PIA-encapsulated APIs not work in a Shared Add-in that would work in a VSTO Add-in?
How can I tell whether the project I’m developing is a VSTO Add-in or a Shared Add-in?
- Is there some set of Imports/Using statements that only work in one or the other (e.g. Imports Microsoft.Office.Core vs. Imports Microsoft.Office.Interop.Word)?
- Do certain Visual Studio Templates lead to either Shared Add-ins or VSTO Add-ins (e.g. Visual C# > Office > 2003 Add-ins > Word Add-in vs. Visual C# > Office > 2007 Add-ins > Word Add-in vs Visual C# > Office > Word Document)? Or is it only relevant if the template used is Other Project Types > Extensibility > Shared Add-in?
- Once I’ve created the project/solution, and if I don’t remember 100%, is there some filename, configuration setting, unique Event or other property of the project that would definitively indicate that it’s VSTO vs. Shared (e.g. ThisAddIn.vb, ThisAddIn_WindowActivate())?
For me, the specific issue that I have been having issues with, and which I’m beginning to suspect has a different solution depending on “Shared” or “VSTO” (despite the lack of clarity or obviousness in any of the sample code you’ll find on the ‘net), is the specific means by which a custom Event Handler can be created for CommandBarButtons in a managed add-in for Word 2003.
I’ve personally seen both code like this (C#):
uiButton.Click += new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler(uiButton_Click);
and like this (VB):
Private WithEvents uiButton As Microsoft.Office.Core.CommandBarButton
It’s entirely UNclear whether these are exactly equivalent, and if not, under what environmental conditions/constraints one is better than the other. It’s also completely beyond me whether this would be considered part of a VSTO add-in or a Shared add-in. Finally, I wouldn’t have a clue what I should do differently were I to know which type of add-in this was – would it affect which of these two handler-setup approaches I used? What types of objects I should use? Something else?