As you may know, the Entity Framework supports mapping database information to POCO (Plain Old CLR Objects) classes in .NET 4. Normally, giving you control over your classes would mean we lose out on a few benefits on controlling the classes ourselves, such as lazy loading and change tracking capabilities. However, if your classes meet a few requirements, then we can dynamically create an assembly at runtime which contains classes that inherit from your POCO types. Today these classes add additional behavior such as lazy loading and change tracking, but in future releases we could potentially augment them to add more features. Typically we refer to these dynamic classes as POCO proxies.

The Entity Framework uses the features in the Reflection.Emit namespace to generate these classes. If you check out Reflector, you can see that the System.Data.Objects.Internal.EntityProxyFactory.GetDynamicModule starts this process by calling AppDomain.CurrentDomain.DefineDynamicAssembly with the AssemblyBuilderAccess specified in the s_ProxyAssemblyBuilderAccess field. During normal execution, s_ProxyAssemblyBuilderAccess is AssemblyBuilderAccess.Run and will never change, but we added this field as a test hook for other purposes. As a result, you can also save the assembly to disk by setting the s_ProxyAssemblyBuilderAccess field to AssemblyBuilderAccess.RunAndSave with reflection.

You can’t just save the assembly right away, since we lazily emit new types into the dynamic assembly as they’re requested. You’ll need to force the Entity Framework to create proxy types by calling ObjectContext.CreateProxyTypes with a list of all POCO types for which you want proxies generated. Then you can save the assembly to disk by calling AssemblyBuilder.Save on the dynamic assembly. If that sounds complicated, don’t worry. We’ll walk through some code to make these steps more concrete. Please note that you’ll need to run in full trust or at least have ReflectionPermission with ReflectionPermissionFlag.MemberAccess to run the code below.

I’ve attached a solution to this post that shows the code in more detail, but let’s walk through the major parts. To set up, I’ve created an Entity Data Model based on the Northwind database, and I’ve used our POCO templates to create classes that the Entity Framework will create proxy types for. The first step is to set the s_ProxyAssemblyBuilderAccess field via reflection.

C#

Type entityProxyFactoryType = Type.GetType(

    "System.Data.Objects.Internal.EntityProxyFactory, " + typeof(ObjectContext).Assembly.FullName);

 

const BindingFlags bindingFlags = BindingFlags.NonPublic | BindingFlags.Static;

entityProxyFactoryType.GetField("s_ProxyAssemblyBuilderAccess", bindingFlags)

    .SetValue(null, AssemblyBuilderAccess.RunAndSave);

VB

Dim entityProxyFactoryType As Type = Type.GetType(

        "System.Data.Objects.Internal.EntityProxyFactory, " + GetType(ObjectContext).Assembly.FullName)

 

Const bindingFlags As BindingFlags = BindingFlags.NonPublic Or BindingFlags.Static

entityProxyFactoryType.GetField("s_ProxyAssemblyBuilderAccess", bindingFlags) _

    .SetValue(Nothing, AssemblyBuilderAccess.RunAndSave)

Next, we need to force the creation of proxy types. Here we’re using a variable context that represents an ObjectContext we’re interested in generating proxies for. (Its instantiation is not shown.) Fortunately, the CreateProxyTypes method ignores any types that are not represented by the model, so we can call the method passing all types in the current assembly.

C#

context.CreateProxyTypes(Assembly.GetExecutingAssembly().GetTypes());

VB

context.CreateProxyTypes(Assembly.GetExecutingAssembly().GetTypes())

Finally, we need to access the AssemblyBuilder using a bit of reflection and call its Save method.

C#

var moduleBuilders = (IDictionary<Assembly, ModuleBuilder>)

    entityProxyFactoryType.GetField("s_ModuleBuilders", bindingFlags).GetValue(null);

 

var pocoProxyModule = moduleBuilders[typeof(NorthwindEntities).Assembly];

var pocoProxyAssembly = (AssemblyBuilder)pocoProxyModule.Assembly;

 

pocoProxyAssembly.Save("EntityProxyModule.dll");

VB

Dim moduleBuilders = DirectCast(

        entityProxyFactoryType.GetField("s_ModuleBuilders", bindingFlags).GetValue(Nothing),  _

        IDictionary(Of Assembly, ModuleBuilder))

 

Dim pocoProxyModule = moduleBuilders(GetType(NorthwindEntities).Assembly)

Dim pocoProxyAssembly = DirectCast(pocoProxyModule.Assembly, AssemblyBuilder)

 

pocoProxyAssembly.Save("EntityProxyModule.dll")

After the preceding code runs, you’ll be left with a file named EntityProxyModule.dll in the current directory, which you can easily pop into Reflector to view the code for the proxies. As you can see the names of the generated types are quite long. Since proxies today are tied to the metadata of the ObjectContext by which they were created, we use a hash of the metadata in the proxy’s type name to correlate the proxy type with that ObjectContext. If we need to use the same CLR type for an ObjectContext with different metadata, we will create a new proxy type.

I’m not going to dive deep into the proxy code, since it resembles code from the default code generation in some ways (e.g. change tracking, relationship management). There is one interesting piece that I’ll point out and that is how we override navigation properties.

Our overrides are very simple—usually we delegate to the base implementation, but if lazy loading is enabled we will call into a delegate (ef_proxy_interceptor…), which is where we will load the navigation property into memory if it’s not there already. Of course, in the proxy code there is nothing specific to lazy loading; we just call a delegate that could do any number of things in future.

I encourage you to download the solution and play around with the code. Let me know here or on our forums if you have any additional questions!

In a previous tip I discussed how you could re-enable CAS policy in applications running in .NET 4 by adding a switch to the application configuration file. However, Constantin Baciu brought up that even when using this configuration switch in a web.config, ASP.NET still threw the SecurityException:

This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information.

Definitely a confusing error message, since you already added the NetFx40_LegacySecurityPolicy configuration switch. The problem is that in order for this switch to actually work, it must be in the executable’s application configuration file. Putting in the web.config has no effect; the switch must be in the configuration file for the server executable, like IIS or Visual Studio’s local web server. Since just about all web hosts I know of won’t let you modify the configuration file for the server, we need a different option.

Fortunately, ASP.NET does support enabling CAS policy in .NET 4, but it’s with a different switch in the web.config. Enter the new legacyCasModel attribute of the trust element. This is the same element that allows you to configure the trust level of the application.

This enables you to get past the SecurityException above, but keep the following things in mind:

• You will be using the legacy security configurations from .NET 3.5 when using ASP.NET. These permission sets are kept in the runtime directory’s Config folder and have names like legacy.web_mediumtrust.config and legacy.web_minimaltrust.config.
• Security asserts are no longer required when only full trust code is on the call stack. This is because ASP.NET will still set up a fully trusted AppDomain, because it relies on CAS Policy to apply specific permissions to assemblies. In .NET 4 ASP.NET sets up a sandbox AppDomain by default, which means that even if only fully trusted code is on the call stack, as soon as a permission demand occurs, the stack walk will fail once it hits the AppDomain boundary.
• Of course, CAS Policy is now enabled, which means the machine’s policy configuration affects what permissions an assembly has.

Legacy CAS Policy at the AppDomain Level

When you specify the legacyCasModel attribute in the web.config, ASP.NET uses that information to set up an AppDomain that has legacy CAS policy enabled. The good news is that by using some lower-level APIs, you can do the same thing.

You may ask "why would you want to do this?" One scenario I can think of is for an existing application that uses AppDomains to isolate other pieces of code (e.g. for add-ins), but some of these old pieces of code use the older security APIs that are obsolete in .NET 4.

The key API is AppDomainSetup.SetCompatibilitySwitches; remember that when setting up an AppDomain you can optionally use an instance of the AppDomainSetup class to initialize the AppDomain. The code example below shows how this is done.

C#

VB

And that’s all there is to it.

One thing I will highlight is that the templates won’t be released with the final version of Visual Studio 2010. Instead we will continue to push releases through the Visual Studio Extension Gallery. This means you can easily download the POCO Templates using Visual Studio’s Extension Manager (accessed through the Tools menu).

Once in the Extension Manager, click the Online Gallery tab on the left side of the window and use the search box (top right) to type in "POCO template." After a few seconds you should see the POCO template extensions appear. There are two extensions, one for C# and one for Visual Basic.

After you install the extension, you’ll have a new item template for C# projects or Visual Basic projects (depending on which you installed) that will allow you to generate POCO entities from an Entity Framework model. For more in depth information on how to use the POCO templates, have a look at the POCO Template Walkthrough.

As always we are interested in your feedback so feel free to request features or report bugs through the Microsoft Connect web site.

Today I’m going to talk about an issue I saw recently with a 64-bit machine and the partial trust tests for the Entity Framework. Even though .NET 4 disables CAS policy, it is more interesting for the Entity Framework to test with CAS policy enabled, because this allows us to configure security permissions on a per-assembly basis instead of per-AppDomain. The workflow for the tests is similar to the following:

1. Enable CAS policy.
2. Use the System.Security.Policy APIs to configure the correct set of permissions for the test assemblies. (Some have ReflectionPermission, some don’t, etc.) This is a separate EXE from the next step.
3. Initialize the test harness and run the test cases.

When running in our lab recently, a few test cases failed for reasons I could not explain. Further analysis revealed that the tests were running in full trust, and so these negative test cases failed because the expected exceptions were not thrown. How did this happen?

Diagnosis

The first thing I did was to experiment with the command line switches of caspol.exe. I started a new command prompt and ran the following command. The –rsp switch stands for resolve permission set. System.Data.Test.PartialTrust.Caller.dll is the name of one of the assemblies that needs a custom permission set.

caspol.exe –rsp System.Data.Test.PartialTrust.Caller.dll

Microsoft (R) .NET Framework CasPol 4.0.21006.1
Copyright (c) Microsoft Corporation.  All rights reserved.

WARNING: The .NET Framework does not apply CAS policy by default. Any settings
shown or modified by CasPol will only affect applications that opt into using
CAS policy.

Please see http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

Resolving permissions for level = Enterprise
Resolving permissions for level = Machine
Resolving permissions for level = User

Grant =
<PermissionSet class="System.Security.PermissionSet"
version="1"
Unrestricted="true"/>

Success

This had at least confirmed my suspicions that the tests were running in full trust. I looked back at the original executable code that configures the policy for the assemblies. It did not seem out of the ordinary, and besides, it had worked in many previous test runs.

C#

VB

My next plan of attack was to determine whether the changes to security policy were really being made. Even though no exceptions were thrown, I couldn’t understand why caspol –rsp would tell me that the framework would run our test assembly in full trust. i tried listing all the code groups from caspol under the Machine level:

caspol –m –lg

Microsoft (R) .NET Framework CasPol 4.0.21006.1
Copyright (c) Microsoft Corporation.  All rights reserved.

WARNING: The .NET Framework does not apply CAS policy by default. Any settings
shown or modified by CasPol will only affect applications that opt into using
CAS policy.

Please see http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

Policy change prompt is ON

Level = Machine

Code Groups:

1.  All code: Nothing
   1.1.  Zone – MyComputer: FullTrust
      1.1.1.  StrongName – 00240000048000009400000006020000002400005253413100040
0000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE
79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E82
1C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8
A12436518206DC093344D5AD293: FullTrust
      1.1.2.  StrongName – 00000000000000000400000000000000: FullTrust
   1.2.  Zone – Intranet: LocalIntranet
      1.2.1.  All code: Same site Web
      1.2.2.  All code: Same directory FileIO – ‘Read, PathDiscovery’
   1.3.  Zone – Internet: Internet
      1.3.1.  All code: Same site Web
   1.4.  Zone – Untrusted: Nothing
   1.5.  Zone – Trusted: Internet
      1.5.1.  All code: Same site Web
Success

The custom code groups weren’t there! But if I inspected the code groups in code after running the setup executable, then they did appear.

Resolution

Eventually I just got frustrated and pulled out procmon to figure out what caspol.exe was doing under the covers. I saw it reading and writing from configuration files in the .NET Framework directory, and that’s when it hit me. The setup executable that writes to security policy was compiled as AnyCPU and thus any security policy edits were flushed to the configuration files in the %WINDIR%\Microsoft.NET\Framework64 directory. Our test harness was erroneously running as a 32-bit application on a 64-bit machine, which means the security policy it read was actually from the %WINDIR%\Microsoft.NET\Framework directory!

There are two versions of caspol.exe on 64-bit machines! One is for 32-bit applications, and the other is for 64-bit. As you can probably infer, I was incorrectly using the 32-bit one in my diagnosis above, which is why I never saw any of the custom code groups added to security policy.

It took a couple hours to figure this out, so I hope this post can help save you some time if you ever run into a similar situation!

One use case where asserts are beneficial is in testing products in partial trust. Say we have some test code that runs in partial trust and calls LINQ to SQL to test that a certain scenario still works in a medium trust environment. However, the test framework that the test uses requires permissions that are not granted in medium trust for some operations. Since the test framework knows that its callers won’t do anything malicious, it can assert for the permissions it needs to run these privileged operations. To do this, however, the test framework must be fully trusted.

Let’s say I have a test that runs in medium trust and calls some code in LINQ to SQL to verify that that code path works under medium trust. However, during some part of the test, the test framework itself needs to read an environment variable to determine which version of SQL Server to execute the test against (e.g. SQL Server 2000, SQL Server 2005, or SQL Server 2008).

Here’s the beginning of a test. (Keep in mind that this code is just an example. It doesn’t represent real types that we use in the LINQ to SQL test code, but it does demonstrate security assertions, which is something we do in the test framework.)

And here’s the code in the test framework that the test above calls.

The TestMediumTrust method resides in a test assembly, while the DataContextFactory resides in another assembly which is part of the test framework. When we set up the medium-trust sandbox in which to run the test, we tell the CLR to fully trust the test framework assembly. Full trust implies two things: (1) that SafeCritical and Critical annotations are respected and (2) we can assert for permissions. Remember that security transparent code cannot assert for permissions; this is why the ReadSqlVersion method above must be SafeCritical.

Medium trust code does not have permission to read the SQLVERSION environment variable, so under normal circumstances calling Environment.GetEnvironmentVariable would throw a SecurityException. This is because the .NET Framework itself will do a full Demand for the EnvironmentPermission to read the SQLVERSION variable. Permission Demands walk the entire call stack to ensure that every frame in the stack has the relevant permissions; since the test code runs in medium trust, the CLR will throw once it checks the TestMediumTrust method.

Asserts are a way to tell the CLR to stop checking for permissions past a particular stack frame. Thus with the assert in place on the ReadSqlVersion method, the EnvironmentPermission check stops prematurely and the permission Demand will succeed. To put that graphically…

So what changes in .NET 4? The recommended guidance is now to assert for full trust instead of for a specific permission. This advice seems to contradict the principle of least privilege, but in reality, if you layer your transparent and critical code appropriately, then security transparency can help you realize least privilege much more effectively. A second reason is that asserting for a specific permission causes a dependency on the underlying implementation. (This is a less convincing argument for me personally.) So the ReadSqlVersion method above now becomes…

The reason for the two different versions is that a permission Demand is expensive because it has to check the permissions of every frame in the call stack. If you know that you aren’t introducing a security hole by calling an unsafe method, then you can skip the permission Demand and avoid the performance hit.

In .NET 4 under the Level 2 security rules, LinkDemands have been replaced by the SecurityCriticalAttribute, which means the UnsafeDeserialize will look similar to this.

Methods annotated with LinkDemands should migrate to use the SecurityCriticalAttribute because the whole purpose of security transparency is to promote this kind of safe/unsafe API layering. When a method is decorated with the SecurityCriticalAttribute, the CLR ensures that no security transparent code can call that method. When you consider that all code running in partial trust is security transparent, the SecurityCriticalAttribute is effectively the same as a LinkDemand for full trust.

Be careful though! This API layering works for the .NET Framework because the assemblies are installed in the GAC and are therefore fully trusted, even in a partial trust sandbox. If the assembly you create is loaded into a partial trust sandbox but is not fully trusted, then the SecurityCriticalAttribute will not enforce anything. Remember, all partial trust code is security transparent, even code annotated with the SecurityCriticalAttribute.

Finally, if your assembly is not intended for partially trusted callers, then do you don’t need to worry about any of this.

Check out the .NET 4 documentation on Demands vs. LinkDemands for more information.

There are only two cases here—a level 1 assembly calling a level 2 assembly, and a level 2 assembly calling a level 1 assembly. Let’s take them one at a time.

Level 2 Assembly Calls Level 1 Assembly

Transparency rules are not enforced across assembly boundaries under the level 1 rules, but they are under the level 2 rules. When a level 2 assembly calls a level 1 assembly, transparency violations are not enforced—that is, if level 2 transparent code calls a level 1 critical method in another assembly, the call succeeds.

Level 1 Assembly Calls Level 2 Assembly

You might think that transparency is enforced across the assembly boundary since the roles are now reversed, but the CLR acts a bit more interestingly than that. If partial-trust code from a level 1 assembly tries to call a critical method in a level 2 full-trust assembly, then the call fails. Level 1 assemblies, which use the CLR v2’s transparency semantics, have no way to interpret a public security critical method as it exists in level 2; such a concept didn’t exist back in the second version of the CLR. Because of this, the CLR goes to great lengths to make everything appear as level 1 to the calling assembly. To do this the CLR transforms the method marked SecurityCritical into a LinkDemand for FullTrust. Thus the call to a public critical method from partial trust code fails.

In the CLR v4, methods that were marked with LinkDemands for FullTrust are now marked SecurityCritical, which is a stronger enforcement mechanism because it prevents all partial-trust code and all transparent code from calling it. It is not a stretch to see that the CLR will transform the SecurityCritical annotation back into a LinkDemand for FullTrust to make everything appear as level 1 to the level 1 assembly.

This means that transparent code in a level 1 assembly can call public critical code in a level 2 assembly if the level 1 assembly is fully trusted. The rule states only that partial trust code in a level 1 assembly cannot call fully trusted security critical code in a level 2 assembly.

Furthermore, partial trust code is always security transparent and thus can never call security critical code.

The first and more important piece is the version of transparency that your assembly follows. If you want to use the .NET 2.0 interpretation of transparency, specify SecurityRuleSet.Level1 as the argument to the SecurityRulesAttribute constructor. If you want to use the .NET 4.0 interpretation of transparency, specify SecurityRuleSet.Level2. Level2 is also the default for assemblies built on the .NET 4.0 runtime.

For CLRv2 transparency semantics:

For CLRv4 transparency semantics:

The second piece allows to tell the CLR that you want to skip IL verification of your assembly when it is fully trusted and transparent. Remember, transparent code can’t contain unverifiable code or P/Invokes, so the CLR usually must check that the transparent code it loads does not violate these invariants. You can skip this verification to increase your performance slightly when the JIT compiler compiles your code, but remember that doing this will allow unverifiable code in your assembly. I’d recommend using this only if you don’t have unverifiable code in your transparent assembly.

That last scenario is slightly abstract, so I want to show an example of the difference.

SecurityDriver.exe

SecurityLibrary.dll (Pardon the trivial example of unverifiable code.)

The Main method in SecurityDriver.exe sets up a partial-trust AppDomain and instantiates a new instance of the Program class in that AppDomain. The partial trust code only has permission to execute (SecurityPermission with SecurityPermissionFlag.Execution). When it calls Utility.ExecuteUnsafeCode, the JIT compiler throws a VerificationException because it can’t verify the IL in Utility.ExecuteUnsafeCode.

But if we add this attribute to the SecurityLibrary assembly and ensure that it is fully trusted (by using the StrongName[] parameter of the AppDomain.CreateDomain method), then the JIT compiler will skip IL verification, and "2" will be printed to the console.

Remember, this only works when your transparent assembly is fully trusted.

It can be really hard to keep all this information straight, so I’ve put together a flowchart to help you determine which transparency rules a particular assembly is using. I hope it’s useful!

As you can see, while the number of rules is not totally unmanageable, it can be difficult to keep them straight. There are also a few situations where two different paths lead to the same outcome. For example, your assembly can be fully critical when it is a level 2 assembly marked with the SecurityCriticalAttribute or when it is a level 1 assembly marked with the SecurityCriticalAttribute with SecurityCriticalScope.Everything. Keep in mind that even though the assembly is fully critical in both cases, the meaning of critical depends on the current level, level 1 or level 2. If you need a review, consult my previous tips on CLR v2 transparency and CLR v4 transparency.

It’s almost the same as doing this.

The difference between the implicit static constructor and explicit static constructor is that the implicit constructor performs much better than the explicit one. (You can read more about this difference here.)

What if I deem that the handle itself should be SecurityCritical? This is where things get interesting…

If I instantiate a new Wrapper instance, this code still runs correctly, but if I mark this assembly with APTCA, it fails. What’s happening here?

We get a FieldAccessException whose message is "ConsoleApplication2.Wrapper.handle" and whose stack trace is "at ConsoleApplication2.Wrapper..cctor()." The ".cctor" is the static constructor. From this we can deduce that the static constructor can’t initialize the field, and that’s because the static constructor generated by the compiler is transparent code when we mark the assembly with APTCA.

Unfortunately this is a case in which you must sacrifice performance for security. This might be changed before .NET 4 RTM, but for now, you’ll need to explicitly specify the static constructor and mark it as security safe critical or security critical. (You can mark it security critical because the runtime itself will call the static constructor from native code.)