Dynamic Data with the Entity Framework in Medium Trust

Ah, Microsoft. You've got to love them; otherwise, why would we continue to tolerate them? I get to deal with a lot of interesting questions and issues about ASP.NET in my role as a moderator on the ASP.NET forums, which are sponsored by Microsoft. It's an incredible community, with lots of highly knowledgeable people helping others with gnarly development problems.

Recently, a forum member was having trouble with the new Dynamic Data feature to be released soon with Service Pack 1 to Visual Studio 2008 and .NET Framework 3.5. He was trying to create a Dynamic Data Web site and deploy it to his shared hosting server, which is set to run with medium trust by the hosting company. His site uses the Entity Framework (EF), another new feature of SP1, to provide the data model context, and he found that the application ran fine on his development machine, but wouldn't run when deployed to the hosted server.

The LINQ query to the data model executed with no problem, but the Entity Framework threw an exception:

Type System.Data.Entity.....Provider cannot be instantiated under a partially trusted security policy (AllowPartiallyTrustedCallersAttribute is not present on the target assembly).

My first response was a kind way of saying that the Microsoft developers who are responsible for this class and assembly were too lazy to do the work to make the class callable by partially trusted applications. This despite all the company's noise about Trustworthy Computing and adherence to the security principal of least privilege. It turns out that the answer is a bit more complicated than that although the basic laziness principal holds.

It turns out that the problem happens at run time when ASP.NET dynamically builds the data model, as opposed to the entire EF class being unusable in medium trust applications. More specifically, the problem only affects websites and not web applications, and websites precompiled in full-trust and deployed to partial-trust environments work okay. This is very weird, to say the least. I don't recall running into a medium trust issue that affects only certain project types in Visual Studio, or one where the build can affect the problem.

Microsoft has two potential workarounds. Well, there are actually three, if you have control over the server and don't care about the security of your site: change the application to full trust. That's a bad choice just about every time, so I won't consider it any more here.

The first workaround involves doing an end run around the EntityDesignerBuildProvider, which is the component that causes the need for full trust. This workaround involves separating the EDMX file into the three metadata files that Entity Framework uses at run time. The technique is explained in the ADO.NET team's blog post. Then you copy the resulting CSDL, MSL, and SSDL files to the application's bin directory. You also have to update the metadata section of the connection string to point to those files. Here's how the resulting connection string might look in the web.config file:

You also need to comment out the build provider for the .edmx extension in the web.config file, which uses the type System.Data.Entity.Design.AspNet.EntityDesignerBuildProvider, because it is no longer needed to extract the metadata files from the .demx files and embed them as resources in your output assembly.

A major problem with this workaround is that you'll need to manually extract the metadata every time you modify the entity data model. So if you use an iterative style of development, it's a pain.

The other workaround that Microsoft suggests is to move your EDMX model file into a separate class library file so the metadata files are embedded in its output assembly. You can add a reference to this class library to your Web site project, and there is no need to change the connection string in web.config although you still need to comment out the build provider. This workaround is a bit more automated, because the build process will automatically update the metadata files. But it still means a bit more maintenance work, with the data model outside your website.

I'm grateful to Microsoft's Diego Vega for taking the time to work out and explain these workarounds.

There was some hope that this problem with EF in medium trust Web sites would be resolved by the time service pack 1 is released, but that is not going to happen. Hopefully Microsoft will resolve the problem in the next service pack! But in the meantime, these workarounds should take care of the problem for you.