Re: Sandboxing AppDomain
From: Nicole Calinoiu (calinoiu)
Date: Tue, 23 Aug 2005 14:58:24 -0400
"kris" <firstname.lastname@example.org> wrote in message
> Hi Nicole, I wish you could of heard the slap to my forehead! :)
> Thanks again for your help. By adding full-trust, strong name
> membership code groups for mscorlib and System.Windows.Forms things
> worked wonderfully. I'm a little unclear as to why mscorlib and the
> winforms stuff have different public keys but that's a secondary issue.
They don't. Both mscorlib.dll and System.Windows.Forms.dll are signed with
the same key, which is generally referred to as the "ECMA key". There's
another key that's used for signing some of the other assemblies that ship
with the .NET Framework (e.g.: System.Drawing.dll, System.Web.dll). If you
look under the All_Code\My_Computer_Zone node of the default machine-level
CAS policy, you'll see two code groups that grant full trust to assemblies
signed with each of these keys.
If you found that you needed to add full trust code groups for both
mscorlib.dll and System.Windows.Forms.dll to your app domain policy, that's
probably because your CreateStrongNameMembershipCondition method created a
membership condition based on key, name, and version as opposed to just on
the key. If you want to exclude the name and version from the membership
condition, supply null values for the corresponding constructor parameters.