Managed Add-In Improvements
Today we have the second of two guest posts from Patrick Smith, a program manager on the Office Programmability team.
Overview and Background
Managed code is becoming more and more prevalent in add-ins written for Microsoft Office products. Also shipping around the same time frame as the 2007 Microsoft Office System is the next version of Visual Studio Tools for Office (VSTO). The next version of VSTO has added support for creating application level add-ins. The demand for better support of managed add-ins is clear since with Office 2003, there are a few challenges when running managed code. Among these challenges are security, resiliency, administration, and isolation. Most of these challenges are the result of add-ins based on mscoree.dll which is the loader used by the default VS.NET add-in template.
While there are workarounds to these barriers such as creating a separate unmanaged “shim” to use in place of mscoree.dll, we wanted to make this process better for the products in the 2007 Microsoft Office System. We’ve done exactly that!
The Improvements
As a developer, you can now design your add-in to use a new AddinLoader supplied in a new version of VSTO. This new AddinLoader helps overcome these historical challenges when running managed code in Office:
- The security model – Microsoft Office System 2003 products bases all add-in security decisions based on mscoree.dll which cannot be signed. Because of this security model, the add-in itself can be signed but the Office product would not know it because it is only looking at mscoree.dll. and since it’s only looking at mscoree.dll, no add-in can run when the Office application is set to High security. Now, if an add-in is based on the AddinLoader, the 2007 Microsoft Office System will be able to defer to the .NET security model to make the security decisions for the add-in. This is only possible by using AddinLoader.
- The resiliency model – Microsoft Office System 2003 products will automatically disable add-ins that fail to load so that future problems with the add-in can be prevented, however, since the add-in is actually seen as mscoree.dll, mscoree.dll is the add-in that is disabled rather than the actual managed COM add-in that is causing a problem. This prevents any other mscoree.dll based add-ins from loading as well because the loader itself is disabled. Now the add-in is seen rather than the loader and ill-behaving add-ins can be disabled individually rather than the loader.
- Administration – When viewing the Add-Ins dialog box, mscoree.dll is seen as the add-in name rather than the actual managed COM add-in that is running within mscoree.dll. Once you are running more than one add-in, it becomes difficult to discern which one is which. Now the name of the actual add-in is displayed.
- Runtime Isolation – mscoree.dll loads all add-ins into the default AppDomain. Therefore, with no memory isolation, add-ins can step on each other and affect objects that are shared between add-ins. The new AddinLoader will use separate AppDomains for the add-in and therefore provide isolation to that add-in.
What’s needed
In order to take advantage of these new improvements, you will need to create your add-in using the new version of VSTO. (There is a technology preview of this version located here.
In addition, you’ll need to ensure the following configuration is available on the machine where the add-in is to be loaded:
- Common Language Runtime 2.0 or greater
- VSTO Runtime (from the new version of VSTO)
- CAS policy giving the Add-in full trust
All of these prerequisites can be configured through the setup project for the add-in you create in VSTO.
