Managed Add-In Improvements

加载宏的改进

（译者：原文中有多处出现Managed，笔者认为直译出来反而会很绕口，忽略它也不会影响理解。）

Today we have the second of two guest posts from Patrick Smith, a program manager on the Office Programmability team.

今天，我们发表两篇客串帖子中的第二篇，来自Patrick Smith，Office 程序开发小组的程序经理。

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.

代码在为Office成品编写的加载宏里变得越来越流行了。Visual Studio Tools for Office （VSTO）下个版本和Office 2007大概在同一时间段上市。VSTO的下个版本增加了对在应用软件级创建加载宏的支持。自从Office 2003开始，代码的更好支持的需求就已经清楚了，但是，运行代码时会有一些挑战。在这些挑战中有安全，恢复，管理和隔离。这些挑战中的大多数都是由于加载宏基于mscoree.dll而导致，mscoree.dll是缺省的VS.Net加载宏模板使用的加载器。

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!

有些工作区域是针对这些障碍的，例如创建一个单独的“shim”来代替mscoree.dll，我们想要让Office 2007系统中的这个过程变得更好一些。我们正是那样做的！

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:

改进

作为一名开发者，你现在可以使用VSTO新版本提供的AddinLoader来设计你的加载宏了。在Office里运行代码时，新的AddinLoader帮助克服那些历史挑战。

• 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.

• 安全模式——Office系统2003产品架构里的所有加载宏的安全决定都是基于mscoree.dll，它是不可签名的。正因为该安全模式，加载宏本身不可签名，而Office产品也不会知道，因为它只看mscoree.dll，并且，因为只看mscoree.dll，所以当Office应用软件设置安全性为高时，没有加载宏可以运行。现在，如果加载宏是基于AddinLoader的话，那么Office 2007系统就能够区别.NET安全模式，为加载宏决定安全性。只有使用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.

• 恢复模式——Office 2003系统的产品会自动禁用加载失败的加载宏，因此，就可以避免该加载宏以后的问题，然而，因为该加载宏实际上是被看作mscoree.dll的，mscoree.dll是被禁用的加载宏，而不是实际上导致该问题的COM加载宏。这就会防止任何基于mscoree.dll的加载宏加载，因为加载器本身被禁用了。现在，看的是加载宏而不是加载器，具体有错误行为的加载宏被禁用，而不是加载器被禁用。

• 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.

• 管理——当查看加载宏对话框时，mscoree.dll就会被看作是加载宏名称，而不是实际在mscoree.dll里运行的COM加载宏。一旦你在运行多个加载宏，就很难辨别哪个是哪个了。现在，显示的是实际的加载宏的名称了。

• 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.

• 运行时间隔离——mscoree.dll将所有加载宏加载到默认的AppDomain。因此，没有内存隔离，加载宏可以相互步入，影响加载宏之间共享的对象。新的AddinLoader将给每个加载宏使用独立的AppDomains，因此，实现了对该加载宏的隔离。

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.

需要什么

为了利用这些新的改进，你将需要使用VSTO新版本（这里有篇对该版本的技术概述）来创建你的加载宏。

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

另外，你需要确保在加载宏加载的机器上有下述配置可用：

• Common Language Runtime 2.0或以上版本

• VSTO Runtime（来自VSTO的新版本）

• CAS政策给加载宏充分信任

All of these prerequisites can be configured through the setup project for the add-in you create in VSTO.

所有这些前提条件都可以从你在VSTO里创建的加载宏的安装工程里配置。