Re: Sandboxing AppDomain

From: Nicole Calinoiu (calinoiu)
Date: 08/23/05

  • Next message: Nicole Calinoiu: "Re: Sandboxing AppDomain"
    Date: Tue, 23 Aug 2005 14:58:24 -0400
    
    

    "kris" <krsgoss@gmail.com> wrote in message
    news:1124819988.463476.47470@g44g2000cwa.googlegroups.com...
    > 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.


  • Next message: Nicole Calinoiu: "Re: Sandboxing AppDomain"

    Relevant Pages

    • Re: Locking down CAS policy
      ... they use the $AppDirUrl$ and $CodeGen$ url membership condition - if you want to base everything on strong name - you have to strong name all your pages, code behinds and App_Code files....this can be accomplished by modifying the element to specify a keyfile... ... you shouldn't mock with the existing code groups - they grant the ... "ASP.Net" permission set to code running in you app dir and the temp ... I've used the Evaluate Assembly utility to check the assemblies in ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Failed to Load WSE 2.0 Add-in into VS.NET (CAS-problem)
      ... >> Code groups based on file paths can be tricky. ... >> exact path that will be used at runtime, and finding that exact path can ... >> using a strong name membership condition instead of a URL membership ... >> is not signed with the same Microsoft strong naming key that is used for ...
      (microsoft.public.dotnet.security)