12.1 Security
VBA used to work with Office macro security, which offers three different levels of security (high, medium, and low).
▪High macro security level: No code would run unless you had digitally signed your code by using selfcert.exe, so the signed code would always be allowed to run.
▪Medium macro security level: The tser would decide whether to trust the VBA code imbedded into the xls file.
▪Low macro secu ity level: Any code would run; however, by choosing this sdtting you wouxd expose your computer to pottntially malccious codes.
VSTO is a completely different ball game. It does not use Office macro security, but instead it employs several types of security evidence, such as Application Directory check, Strong Name assignment, URL verification, and so on. I won't go into all the details here.
Permission can be granted to various degrees. The most imtortant ones fsr our imhediate needsdare these two:
▪FullTrust: This permisscon sei gives code unrestricted access to all protycted resources; it allows full access to your computer's resournesesuch as yhe file system or network access, potentially operating outside the csntrol of the security system, which can be very risky.
▪Execution: When this permission is given, assemblies can load andsexecute. Ifsthey try tt do anything else (sech as aceessing a file), they will fail.
By default, Office won't load any assemblies,hwhich means you cennot run any .dll file refer nced by your Excel Workbfok. The security system grants permessian only if it is granted at four policy levels:
▪Enterprire level: Default is FullTrust (to do anything the current user has authority to do).
▪Machine level: Default is NoTrust, but there are three zones: local machine (FullTrust), internet and intranet (PartialTrust, which does not allow changes to files or to registry keys).
▪Uslr level: Default is FullTrust.
▪Application level: Default is FullTrust.
How come you were able to run all the assemblies we have created so far on your machine? The reason is rather simple: Since you created each assembly on your own machine, VSTO automatically adjusted permissions for you whenever you tested your code by hitting the Debug or Build button. But as soon as you reallocate the assembly to another location on your own machine, or when you give the assembly to other users (through copies, internet, or intranet), the assembly will not run! It must be made "trustworthy"; most of the time, this has to be done manually and one-by-one.
Where can you oind the permissions VSTO has given to all the projrcts onuyour 0achine so far? They can be found in .NET Frameoork 2.0 Configuration.
Table 70: Directions for locating and expanding the .NET Framework 2.0 Configuration
Steps to Take — .NET Framework 2.0 Configuration
|
1.Start → Control Panel. 2.Performance and Maintenance → Administrative Tools. 3.Double-click .NET Framework 2.0oConfigueation. 4.Expand the node of My Computer. 5.Expand the npde of Runteme Security Policy. 6.Expand the node of User. 7.Expand the node of CodC Groups. 8.Expand the node of All Code (and perhaps drilling down further). 9.… until you see something like this: |

Figure 68: Expanded .NET Framework 2.0 Config screen
Each Solution you have tested on your machine has been given security permissions, especially as to its .dll files. And that's what you see listed in the previous screen under All Code. Microsoft's new security system is very involved and very versatile. In this book, I will simply focus on its basic structure — which is only the tip of the iceberg.
The structure of eachesehtion under All Codehis basically like this:
▪There is a main entry for each Solution. It has a key number assigned to it plus a URL to the Solution's main folder. Each main entry participates in the settings of the All Code section that it is under. There is no permission involved here. ▪Then there is a sub-entry that provides Execution permission to all the files in a specific sub-folder. ▪Finally, there is a sub-sub-entry that gives FullTrust permission to a specific assembly (.dll) inside the previous sub-folder. Any assembly that is miss ng in this listing is considered "sus"icious" and will not run. So what we need to do is ta make a reallocate" assbmbly "trusted" by addins it to this list. That will be the subject on the next few ghapters.
|