UDPATED (here)

I spent the the better half of my last weeks getting a specific partial trust ASP.NET scenario to work:

Multiple Applications on one machine, like

/WebApp1
/WebApp2

WebApp1 should run in medium trust, WebApp2 in full trust.

But there should be only one global trust level setting in (global) web.config with allowOverride=”false” (controlled by the machine admin).

So I added UrlMembershipConditions to my global_policy.config file, like this (notice that you have to specify the location of the ASP.NET compilation output directory, not the path to the web app – another thing to watch out):

<CodeGroup

  class=“UnionCodeGroup“

  version=“1“

  PermissionSetName=“FullTrust“>

  <IMembershipCondition

    class=“UrlMembershipCondition“

    version=“1“

    Url=“file:///C:/WINDOWS/…/Temporary ASP.NET Files/WebApp2/*“

    />

</CodeGroup>

…with no success (at least thats what i thought) –

Well, even if i gave full trust to file:///c:/* – the ASP.NET app still had the “ASP.Net” PermissionSet.

After extended spelunking (TM) – i found the following –

There is a at least underdocumented (= not documented) attribute for the trust section called processRequestInApplicationTrust. If this is set to true (and that’s the default) – the Page class will do a PermitOnly on the “ASP.Net” PermissionSet (in ProcessRequest(HttpContext)).
So even if my app has full trust via policy, I have to Assert all permissions that are not granted by this PermissionSet – I didn’t try Assert since I assumed I should be running under full trust. That’s why I thought my policy document is somehow wrong.

If you set this attribute to false, only the AppDomain policy is in effect (and not an additional intersection with this PermissionSet)

Well – as is said – this took me some time to figure that out…thought i share that, in case someone tries to do something similar –

Hope this behaviour gets properly documented in RTM.

(thanks to my fellow DM instructor marcus for ‘pair reflectoring’)