Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath [Electronic resources] نسخه متنی

Location, Location, Location

One of the most straightforward ways to ensure that customized Word and Excel documents can run is to set a policy that states that customization assemblies that run from a particular place are fully trusted. You might have Web servers or file shares on your network where write access is restricted to trusted individuals; if the customization is there, that is pretty good evidence that it is trustworthy.

You can set an Enterprise-level policy that states that customization assemblies at a particular location are fully trusted by right-clicking the All Code code group in the Enterprise policy level and selecting New from the menu. Doing so causes the Create Code Group dialog to appear, as shown in Figure 19-3.

Enter a name for the code group and a description to help others understand what the code group is intended to do. Then click the Next button. The Create Code Group dialog shown in Figure 19-4 will appear. Choose a URL membership condition from the condition type drop-down box. For the URL, give the location to which the VSTO customization assembly will be deployed. In Figure 19-4, we are matching any customization assemblies in the Web folder http://accounting/customizations because we used the * wildcard in the URL.

After you have chosen the URL condition type and entered a URL, click the Next button. The third step of the Create Code Group dialog displays, as shown in Figure 19-5. Select the Use existing permission set radio button and select FullTrust as the permission set to be granted to the code group.

But hold on a moment. Clearly, this is not going to work. Remember, the policy evaluator only grants a permission if it is granted by

all four code groups. When a user runs this customization, the Enterprise and User policy levels will grant full trust because of their root All Code code group. The AppDomain policy level will grant full trust because the Enterprise policy level contains a URL code group that grants full trust. But what about the Machine policy level? It will take one look at that thing, classify it as being from the LocalIntranet Zone, and grant it the LocalIntranet permission set. Because the customization assembly requires full trust, it will not run.

We have a problem here. You could, of course, solve this problem by setting the policy at the Machine level rather than the Enterprise level. Or you could set it at both levels. In the system described so far, however, policy levels can only add additional restrictions; it seems sensible that an enterprise administrator would be able to override the restrictions of a machine administrator. We need a way for a policy level to say "grant full trust even if another policy level disagrees."

Fortunately, we can tweak the code group to achieve this. Right-click the code group you just created, and choose Properties. Take a look at the check boxes at the bottom of the Properties dialog (see Figure 19-6).

Checking the first check box makes this an "exclusive" code group; the regular rules about combining the permission sets of different code groups to determine the grant set for a particular policy level cease to apply. Checking the second check box makes this a "level-final" code group; policy levels from the "lower" code groups are ignored if the code's evidence matches the membership condition for this group.

What does "lower" mean? The Enterprise code group is the highest, then Machine, User, and finally Application Domain is the lowest.