DynamicMethods, as their name implies, are methods created at runtime that are associated with an existing module or type, or a transparent assembly provided by the framework (aka an anonymously hosted DynamicMethod). There are different considerations for each, so we’ll tackle them one at a time.

Existing Module or Type

DynamicMethods can be associated with existing .NET modules and types by using the appropriate constructor overload of DynamicMethod that accepts either a Module or a Type as an owner. Using one of these constructors allows you to create a method that is logically associated with that owner, which means it has access to any non-public members within that same scope. The MSDN documentation has a great example of how to use this functionality.

Unfortunately, this example fails in medium trust because of one of the many security checks that DynamicMethods do in the case when there is an existing owner:

1. If the DynamicMethod is associated with a Type, then if it is invoked from a Type that does not match the owner, then ReflectionPermission/MemberAccess is demanded.
2. If the DynamicMethod is associated with a Module, then if it invoked from an Assembly that does not match the owner Module’s Assembly, then ReflectionPermission/MemberAccess is demanded.
3. If the skipVisibility constructor parameter is set to true, then ReflectionPermission/MemberAccess is demanded.

These restrictions make associating DynamicMethods with existing modules or types almost impossible in partial trust. But if you find that you still want to do this, you should find out about additional restrictions from Shawn’s blog on the topic. (For example, what stops me from associating methods with modules and types from .NET Framework assemblies?

Anonymously Hosted

The solution to the problems above is to place your DynamicMethods in an anonymously hosted security-transparent assembly provided by the .NET Framework. Doing this simply requires you not to specify an owner Module or Type in the constructor for the DynamicMethod.

This narrows down your constructor choice from eight to two; the only difference between them is a very interesting parameter called restrictedSkipVisibility.

When this parameter is set to false, the JIT compiler treats the DynamicMethod like any other method in your code; that is, it can access all public members in other assemblies. If the parameter is true, that means the DynamicMethod can access non-public members in other assemblies without using reflection. This feature is subject to the restriction that the accessed assemblies must have a trust level that is equal to or less than the trust level of the call stack that emits the dynamic method. This check is done only at JIT compilation time and not during subsequent invocations of the method.

If you’re familiar with ReflectionPermission/RestrictedMemberAccess this pattern of demand probably sounds familiar to you. In fact, the mechanism is largely the same with the interesting difference that the demand for the appropriate permission is done against the call stack that was present when the DynamicMethod was created. Let’s look at a couple of examples.

First, let’s look at the power of restrictedSkipVisibility. Below, I have declared an interface, ICalculator, with an internal implementation named PrivateCalculator.

[sourcecode language="csharp"]
public interface ICalculator
{
    int Add(int left, int right);
}

internal class PrivateCalculator : ICalculator
{
    public int Add(int left, int right)
    {
        Console.WriteLine("Inside PrivateCalculator.Add.");
        return left + right;
    }
}
[/sourcecode]

So far, so good. Now let’s create a dynamic method that manufactures ICalculator instances.

[sourcecode language="csharp"]
public class Program : MarshalByRefObject
{
    static void Main(string[] args)
    {
        var ps = new PermissionSet(PermissionState.None);
        ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution | SecurityPermissionFlag.Infrastructure));
        ps.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.RestrictedMemberAccess));

        AppDomain d = AppDomain.CreateDomain("Sandbox", null, new AppDomainSetup { ApplicationBase = Environment.CurrentDirectory }, ps);

        var x = (Program)d.CreateInstanceAndUnwrap(typeof(Program).Assembly.FullName, typeof(Program).FullName);
        x.PartialTrustMain();
    }

    public void PartialTrustMain()
    {
        var dm = new DynamicMethod("CreatePrivateCalculator", typeof(ICalculator), Type.EmptyTypes, restrictedSkipVisibility: true);
        var ilGenerator = dm.GetILGenerator();

        ilGenerator.Emit(OpCodes.Newobj, typeof(PrivateCalculator).GetConstructor(Type.EmptyTypes));
        ilGenerator.Emit(OpCodes.Ret);

        var createCalculator = (Func<ICalculator>)dm.CreateDelegate(typeof(Func<ICalculator>));
        Console.WriteLine(createCalculator().Add(5, 7));
    }
}

[/sourcecode]

I include Main for completeness, but the real code of interest is inside PartialTrustMain, where I create an anonymously hosted DynamicMethod with restrictedSkipVisibility set to true. The method’s body simply creates a new instance of PrivateCalculator and returns it. Notice I am simply using the IL necessary to call the C# equivalent of "new PrivateCalculator()," and this compiles even though the method will not live in the same assembly as the PrivateCalculator class. If I removed the restrictedSkipVisibility parameter or set it to false, I would receive the following exception:

Unhandled Exception: System.MethodAccessException: Attempt by method ‘DynamicClass.CreatePrivateCalculator()’ to access method ‘CustomDynamicMethodSecurity.PrivateCalculator..ctor()’ failed.

   at CreatePrivateCalculator()

   at System.Func`1.Invoke()

   at CustomDynamicMethodSecurity.Program.PartialTrustMain()

   at CustomDynamicMethodSecurity.Program.PartialTrustMain()

   at CustomDynamicMethodSecurity.Program.Main(String[] args)

If we wanted to achieve the same thing without this parameter, we’d have to write the IL to generate calls against Activator.CreateInstance for the PrivateCalculator type, a verbose and error-prone set of lines to write by hand.

For the second example, let’s change the stakes a little bit. Let’s move ICalculator and PrivateCalculator to a separate assembly that is now fully trusted in the partial trust AppDomain. If we still try to create a PrivateCalculator using the DynamicMethod above, then we’ll encounter the same MethodAccessException that I pointed out earlier. Because PrivateCalculator is now in a fully trusted assembly, it requires full trust in order to create instances of PrivateCalculator from an anonymously hosted DynamicMethod. What else could we do?

Well it turns out we can move the creation of the DynamicMethod to a fully trusted assembly and then pass the delegate returned from DynamicMethod.CreateDelegate back to the console application to invoke. Let’s take a break here and look at the changes made to the code.

This is the console application:

[sourcecode language="csharp"]
public class Program : MarshalByRefObject
{
    static void Main(string[] args)
    {
        var ps = new PermissionSet(PermissionState.None);
        ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution | SecurityPermissionFlag.Infrastructure));
        ps.AddPermission(new ReflectionPermission(ReflectionPermissionFlag.RestrictedMemberAccess));

        AppDomain d = AppDomain.CreateDomain(
            "Sandbox",
            null,
            new AppDomainSetup { ApplicationBase = Environment.CurrentDirectory },
            ps,
            typeof(CalculatorUtils).Assembly.Evidence.GetHostEvidence<StrongName>());

        var x = (Program)d.CreateInstanceAndUnwrap(typeof(Program).Assembly.FullName, typeof(Program).FullName);
        x.PartialTrustMain();
    }

    public void PartialTrustMain()
    {
        var createCalculator = CalculatorUtils.CreatePrivateCalculatorFactory();
        Console.WriteLine(createCalculator().Add(5, 7));
    }
}

[/sourcecode]

And this is the fully trusted assembly:

[sourcecode language="csharp"]
public static class CalculatorUtils
{
    public static Func<ICalculator> CreatePrivateCalculatorFactory()
    {
        var dm = new DynamicMethod("CreatePrivateCalculator", typeof(ICalculator), Type.EmptyTypes, restrictedSkipVisibility: true);
        var ilGenerator = dm.GetILGenerator();

        ilGenerator.Emit(OpCodes.Newobj, typeof(PrivateCalculator).GetConstructor(Type.EmptyTypes));
        ilGenerator.Emit(OpCodes.Ret);

        return (Func<ICalculator>)dm.CreateDelegate(typeof(Func<ICalculator>));
    }
}

public interface ICalculator
{
    int Add(int left, int right);
}

internal class PrivateCalculator : ICalculator
{
    public int Add(int left, int right)
    {
        Console.WriteLine("Inside PrivateCalculator.Add.");
        return left + right;
    }
}

[/sourcecode]

But even with this code we have a problem. The call stack present when the DynamicMethod was created has some partially trusted code in it from the console application. So the last thing we need to do is apply an assert to CalculatorUtils.CreatePrivateCalculatorFactory that stops the stack walk from going into that partially trusted code. The final outcome:

[sourcecode language="csharp" padlinenumbers="true"]
public static class CalculatorUtils
{
    [SecuritySafeCritical]
    [ReflectionPermission(SecurityAction.Assert, MemberAccess = true)]
    public static Func<ICalculator> CreatePrivateCalculatorFactory()
    {
        var dm = new DynamicMethod("CreatePrivateCalculator", typeof(ICalculator), Type.EmptyTypes, restrictedSkipVisibility: true);
        var ilGenerator = dm.GetILGenerator();

        ilGenerator.Emit(OpCodes.Newobj, typeof(PrivateCalculator).GetConstructor(Type.EmptyTypes));
        ilGenerator.Emit(OpCodes.Ret);

        return (Func<ICalculator>)dm.CreateDelegate(typeof(Func<ICalculator>));
    }
}

[/sourcecode]

Now I should hope that it goes without saying but it’s very dangerous to pass around delegates created under an assert like this among class library boundaries. Treat them as radioactive if you must do this, and be sure to review your code for any possible exploitations where code might be able to invoke one of these delegates even though they should not be able to.

Next time, we’ll talk about expression compilation!

One of these scenarios is to use a collection of scalar values (like ints or strings) to represent a relationship, instead of a collection of very simple entity types, each of which has that scalar property. The reason you’d want to do this is because you want to persist the scalar values to the database, but there isn’t any additional information associated with those values to justify a full-fledged entity type. The Entity Framework doesn’t support this today, but in this post I’ll take you through how you can simulate this with your entities.

Show me the code, already!

In this post I’m using the Database First approach to using EF, but I’m sure you can also achieve this same thing in Model First and Code First.

The Model

The domain for this post focuses on albums and songs, and in this simplified model, we are only interested in the name of the song for a particular album.

The conceptual model in EF does not look much different; the only difference from the default generation is that there is no navigation property from Song to Album—that is, there is no Album property on Song.

Everything seems straightforward so far. We’ve decided, though, that since the only property of interest on the Song class is the SongTitle, that the Album class should have a collection of song titles instead of a collection of Songs. I’ll show how this works in the next step.

The Model (Code)

Now unfortunately because we are hacking around the way the Entity Framework works, we have to make some compromises when it comes to the API we expose on the Album class. Ideally, I would like to write something like this:

[sourcecode language="csharp"]
public class Album
{
    public Album()
    {
        this.SongTitles = new HashSet<string>();
    }

    public int Id { get; set; }
    public string AlbumName { get; set; }

    public ICollection<string> SongTitles { get; private set; }
}
[/sourcecode]

Now for this to work with EF I have a couple of requirements:

1. When I query for Albums, the SongTitles must be populated with titles from the related Song entities.
2. When I add or remove SongTitles from an Album that is attached to the ObjectContext, this must be processed as an Add or Delete during the call to SaveChanges.
3. Creating a new Album, populating the list of SongTitles, and then calling AddObject must also ensure that its SongTitles are added to the database when SaveChanges is called.

Let’s take this one step at a time.

Query

When you issue a query to the database, the tuples of data that come back are converted into objects. This process is called materialization. EF4 allows us to use the ObjectMaterialized event to discover when objects are materialized, and we can use this to load the song titles for an album when any Album instance is materialized. Before we get started, though, we need a Song class to query for and a derived ObjectContext class.

[sourcecode language="csharp"]
public class Song
{
    public int AlbumId { get; set; }
    public string SongTitle { get; set; }
}

[/sourcecode]

[sourcecode language="csharp"]
public class ScalarCollectionsContext : ObjectContext
{
    public ScalarCollectionsContext() :
        base("name=EFScalarCollectionEntities")
    {
    }

    public ObjectSet<Album> Albums
    {
        get { return this.CreateObjectSet<Album>(); }
    }

    public ObjectSet<Song> Songs
    {
        get { return this.CreateObjectSet<Song>(); }
    }
}

[/sourcecode]

Since the ObjectMaterialized event is exposed on the ObjectContext, we can subscribe to that event from within the ScalarCollectionsContext constructor. The implementation is fairly straightforward—once an Album is materialized, query for the Songs that are associated with that Album and add all of the song titles in the results to the Album’s SongTitles collection.

[sourcecode language="csharp"]
private void OnObjectMaterialized(object sender, ObjectMaterializedEventArgs e)
{
    var album = e.Entity as Album;
    if (album != null)
    {
        foreach (var songTitle in this.Songs.Where(s => s.AlbumId == album.Id).Select(s => s.SongTitle))
        {
            album.SongTitles.Add(songTitle);
        }
    }
}

[/sourcecode]

One step done.

Adding/Removing SongTitles Processed during SaveChanges

The second step is to make sure that any time we add, remove, or change an item in the SongTitles collection, the corresponding add or delete occurs in the data store. Now you could do this by taking a snapshot of the collection when you query for it and then diffing it with the collection when you save changes, but to make things a little simpler we will instead leverage an ObservableCollection<string> for the SongTitles collection.

Each Album instance can then subscribe to the CollectionChanged event of that collection and register the changes as adds or removes against a private navigation property for Songs. We use the navigation property to make it easier to bridge the gap between our objects and the change tracking capabilities built into the Entity Framework. If that’s unclear, I’ve included the new version of the class below. Note that the SongTitles collection is now an ObservableCollection whose changes update the private Songs collection.

[sourcecode language="csharp" padlinenumbers="true"]
public class Album
{
    public Album()
    {
        this.Songs = new HashSet<Song>();
        this.SongTitles = new ObservableCollection<string>();
        this.SongTitles.CollectionChanged += OnSongTitlesChanged;
    }

    public int Id { get; set; }
    public string AlbumName { get; set; }

    public ObservableCollection<string> SongTitles { get; private set; }
    private ICollection<Song> Songs { get; set; }

    private void OnSongTitlesChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        if (e.NewItems != null)
        {
            foreach (string title in e.NewItems)
            {
                this.Songs.Add(new Song() { AlbumId = this.Id, SongTitle = title });
            }
        }

        if (e.OldItems != null)
        {
            foreach (string title in e.OldItems)
            {
                var song = this.Songs.SingleOrDefault(s => s.SongTitle == title);
                this.Songs.Remove(song);
            }
        }

        if (e.Action == NotifyCollectionChangedAction.Reset)
        {
            this.Songs.Clear();
        }
    }
}

[/sourcecode]

It would seem that we are done. When we query for Albums, their related SongTitles are populated, which also populates the Songs collection since it is an observable collection. Any changes to the SongTitles collection will update the corresponding Songs collection, and the Entity Framework will use that for assessing what changes to the database need to be made. Finally, because we subscribe to the CollectionChanged event from within the Album’s constructor, if we create an Album outside of the context and then add/attach it, its corresponding children will be added or attached as well.

But, there are a couple of problems:

1. Marking the Songs collection private will not work in medium trust.
2. When the SongTitles are populated after querying for Albums, completely new Songs are added to the Songs collection, instead of the existing Songs that were materialized as part of the LINQ query. This means when SaveChanges is called, the Entity Framework thinks that it needs to INSERT all the existing songs as new songs, causing a primary key violation in Songs table.

While the first problem is not something we can fix outside of the framework today, the second one is, and it requires a few changes to the code we have for the ObjectMaterialized event.

[sourcecode language="csharp"]
private void OnObjectMaterialized(object sender, ObjectMaterializedEventArgs e)
{
    var album = e.Entity as Album;
    if (album != null)
    {
        EntityCollection<Song> songs = (EntityCollection<Song>)this.ObjectStateManager
            .GetRelationshipManager(album)
            .GetRelatedEnd("EFScalarCollectionModel.FK_Song_Album", "Song");
        foreach (var song in songs.CreateSourceQuery())
        {
            album.SongTitles.Add(song.SongTitle);
        }
    }
}

[/sourcecode]

Welcome to the nasty side of the Entity Framework, where magic strings abound. This code does a couple of very useful things to help us achieve our goal, so let’s break it down step-by-step:

First we retrieve the EF-centric view of the collection of Songs for the Album that was just materialized. This is an EntityCollection<Song>, a class you may recognize if you have used the Entity Framework with the default code generation in the past. The first magic string passed to GetRelatedEnd method is the namespace-qualified Association name of the relationship between Song and Album; the second is the name of the Role that signifies which "end" of the relationship you want to retrieve. You can find this in the CSDL section of your EDMX file:

[sourcecode language="xml"]
<AssociationSet Name="FK_Song_Album" Association="EFScalarCollectionModel.FK_Song_Album">
  <End Role="Album" EntitySet="Albums" />
  <End Role="Song" EntitySet="Songs" />
</AssociationSet>

[/sourcecode]

Next we iterate over all the Songs in the collection after calling CreateSourceQuery; this allows us to both to load the Songs collection in the Album instance and to populate the SongTitles collection in the same Album instance.

One last problem—we now have duplicate Songs in the collection because SongTitles.Add triggers the CollectionChanged event. But we can fix this simply by ensuring that we don’t add duplicates in the OnCollectionChanged handler. Note the addition of the Where filter on the NewItems collection.

[sourcecode language="csharp"]
if (e.NewItems != null)
{
    foreach (string title in e.NewItems.Cast<string>().Where(t => !this.Songs.Any(s => s.SongTitle == t)))
    {
        this.Songs.Add(new Song() { AlbumId = this.Id, SongTitle = title });
    }
}

[/sourcecode]

And that’s it. This is one way to keep collection of scalars in your POCO entities but project something entirely different to the Entity Framework. Theoretically, this would also work with collections of complex types, although I have not tried it.

Results

If you’re really concerned about a clear separation of concerns, this probably isn’t the greatest solution for you, since there are a lot of concerns that bleed from the Album entity because of the Entity Framework. Granted, the extra properties and methods are all private, but it’s still code you need to wade through every time you make changes to that part of the model.

Now, I have not tried this due to a lack of time, but there might be a way to remove the Songs navigation property entirely if you don’t care about the Song entities being in the state manager at all. If I wanted to do this, I would keep the following things in mind.

• As a consumer of the Album class, all I care about are the SongTitles, so I can make any changes I want to them, including adds, removes, and changes.
• When I call SaveChanges on the ObjectContext, I would need a way to replay changes made to the SongTitles collection against the ObjectContext in terms it understands i.e. the Song entities.
• This means that it would be useful to have a collection that had an initial state and a log of all the changes made to it.
• The initial state is different for Albums created by users versus those created by the Entity Framework due to queries.

There are also some limitations with this approach; for example, Song cannot have any other scalar properties or associations.

I have attached a solution with the final code in both C# and Visual Basic, along with a small number of acceptance tests that verify the requirements I laid out at the beginning of the post. If you decide to implement the alternative where there is no navigation property from Albums to Songs, then you can use these acceptance tests to help you get started.

If there are any other types of "hacks" you’d like to see with the Entity Framework let me know in a comment!

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.

• Astoria
• Entity Framework

Note: If the job descriptions above still say you need C/C++ experience, this is not true. If you don’t have experience in these areas, don’t let that discourage you from applying! In fact, I didn’t have C/C++ experience upon arriving here…

Now, I know what you’re thinking—"ugh, test, you mean those guys who sit on the other side of the building and click on things all day?" And actually, when I first joined as a tester, I had a bit of the same mentality. That’s why I wanted to find out for myself what testers actually do. I have worked at Microsoft for a year now as a tester on the Entity Framework team and have learned a lot about the discipline of test, but I know I have only scratched the surface. Also, I should clarify that these positions are opening on the runtime team, so you won’t be clicking on things that much, if at all.

My background as a .NET developer has really helped me excel as a test engineer. The challenges that we face are very diverse and as a result I think there are many more opportunities for growth in the test discipline than in other disciplines. In a sense, we are developers ourselves; we don’t ship code (typically), but we must have the ingenuity and creativity to verify the code that does ship meets a high quality bar. Test can be a very demanding discipline, especially for those people who have a background in development.

If you want to know more about my experiences feel free to contact me using the contact form page, and I hope you consider applying if you’re looking for a challenging job.

P.S. I should note that the Astoria job description is missing an important sales pitch—you get to work with Pablo Castro! Yes, that Pablo.

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.NETFramework64 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.NETFramework 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.