What are the similarities and differences between Shared Add-In and VSTO application-level Add-In?

Question

What are the similarities and differences between Shared Add-In and VSTO application-level Add-In?

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 1

The similarities of Shared Add-In and VSTO Add-In are:

1.       Both of these are registered in the host application’s registry key, for example, HKCU\Software\Microsoft\Office\Word\Addins. After Office loads these, they will both appear in the COM Add-in Dialog.

2.       They both build upon the COM interface to do Office extensibility by consuming the Office Object Model. They can both add the extensible UIs, like custom task pane, ribbon, outlook form region to Office application.

Since there are many differences between Shared Add-In and VSTO Add-In, we will only mention the key points in the following list:

1.       As the name indicates, one Shared Add-In can be shared among several different Office applications. So, the Shared Add-in needs additional code to discern the host application. However in VSTO Add-Ins, an Add-In can only serve one host application. So, in our Add-In, what we are working on is a strong typed host application. We do not need to cast the application object to a specific one, or call its function via late binding anymore.

2.       To create the UI extensibility for the ribbon, custom task pane, and form region in the Shared Add-In, the programmers have to implement three interfaces, Office.IRibbonExtensibility, Office.ICustomTaskPaneConsumer, Outlook.FormRegionStartup. A lot of manual work is required to write the code, no matter which one of the extensible UIs is created. However, if we are using the Visual Studio Tools for Office, everything is wrapped for us. We just need to add a new Ribbon, UserControl, or FormRegion item into our VSTO Add-In project, because it is now supported to design these three UIs from the VSTO designer. All we need to do is just drag and drop the controls, set properties, and double click to generate event handlers just like the Windows Form Designer.

3.       Another important difference is the security model. There is historically no requirement for IDTExtensibility2 Shared Add-Ins to have any code access security (CAS) policy associated with them. So, before Office can load the Shared Add-In, we do not need to call caspol.exe to grant full trust to the Add-In assembly. For VSTO, up until version 2008 we used .NET security policy. However, the VSTO 2008 uses the Click Once deployment and Authenticode model.

4.       Visual Studio Tools for Office creates a new AppDomain to load each of the VSTO Add-Ins. So, it will not affect each other. Programmers do not need to worry about the "Outlook won't shut down" issue. When the VSTO Add-in shuts down, the AppDomain gets unloaded and it will recycle the resources the programmer has allocated in the application.

5.       VSTO add-ins are installed to HKCU (per user) by default, while the Shared Add-in can be deployed to HKLM. So, if we want to deploy the VSTO Add-in to all users, we need to do some extra manual work. Please read http://blogs.msdn.com/mshneer/archive/2008/04/24/deploying-your-vsto-add-in-to-all-users-part-iii.aspx for detailed information.

(Related forum thread http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/3f97705a-6052-4296-a10a-bfa3a39ab4e7/ )

For more FAQ about Visual Studio Tools for Office, please see Visual Studio Tools for Office FAQ

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.