The answer to the above question should be “nothing, unless you’re trying to build a project that references entity framework”, but apparently it isn’t so.

Say you have a project you’ve built, and you want to build it through code, using the Engine class of Microsoft.Build.Engine assembly.

The code should look something like this (taken from MSDN):

// Instantiate a new Engine object
Engine engine = new Engine();

// Instantiate a new FileLogger to generate build log
FileLogger logger = new FileLogger();

// Set the logfile parameter to indicate the log destination
logger.Parameters = @"logfile=C:\temp\build.log";

// Register the logger with the engine

engine.RegisterLogger(logger);

// Build a project file
bool success = engine.BuildProjectFile(@"c:\somewhere\someproject.csproj");

//Unregister all loggers to close the log file
engine.UnregisterAllLoggers();

if (success)
    Console.WriteLine("Build succeeded.");
else
    Console.WriteLine(@"Build failed. View C:\temp\build.log for details");

Some notes about the code:

When you try to run the code on a project with a target framework of 3.5, you might get an error like this in your log file ('I’ve marked the important stuff in bold):

Target EntityDeploy:
    C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Data.Entity.targets(40,5): error MSB4127: The "EntityDeploy" task could not be instantiated from the assembly "C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Data.Entity.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Data.Entity.Build.Tasks.EntityDeploy' to type 'Microsoft.Build.Framework.ITask'.
    C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Data.Entity.targets(40,5): error MSB4060: The "EntityDeploy" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Done building target "EntityDeploy" in project "SampleClassLibrary.csproj" -- FAILED.

If you look at the Microsoft.Data.Entity.Build.Tasks assembly, you will notice that this assembly uses both versions of Microsoft.Build.Framework – both version 2.0 and 3.5

Of course, if you try to add both versions to your project, it just won’t work, because both have the same name.

So, how can we make it work? just let the application know that it should always use version 3.5, even if version 2.0 is specified (implied in the error message). To do that, you need to add an assemblyBinding to your config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>    
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Build.Framework" 
         publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
      </dependentAssembly>          
    </assemblyBinding>
  </runtime>
</configuration>

And that’s it

Entity Framework supports entity inheritance, which is a basic requirement for O/R mappers.

When exposing a model through a service, either an ASMX WS or a WCF service, a WSDL will be created that among other things describes the structure of the entities, including the inheritance tree of the entities - This is done to allow creation of methods that return polymorphic types.

EF supports derived entities through WCF services with data contract serialization using the KnownTypeAttribute which is added to the base class for every derived class.

To allow the same thing to be done with ASMX web services (that uses the XmlSerializer) a XmlIncludeAttribute needs to be added to the base class for every derived class – something that EF doesn’t do !!!

Without XmlIncludeAttribute, the WSDL will not include information about the derived classes, making the generated proxy in the client accept only base class values, and worse – get a soap exception when a derived type is returned from the service.

The solution for this is simple, yet annoying :

Simple - create a partial class for every base class and add an XmlIncludeAttribute for each derived class. For example, if you have a Person base class and a derived Employee class then the partial class will look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml.Serialization;

namespace EFSample
{
    [XmlInclude(typeof(Employee))]
    public partial class Person 
    {
    }
}

Annoying – since it’s that simple, why doesn’t EF support that?

When we started working with Silverlight 2 Beta 1, we’ve noticed that there is a problem accessing services which reside on a secured server (secured with CheckPoint Secure Remote) – The silverlight client just didn’t pass the client cerificate needed to access the server.

The solution to this was to access all our services from JavaScript, because IE can pass the client certificate to the server. This of course caused us to start thinking on how to write a framework that will allow calling a JavaScript proxy as easy as calling a proxy in C#.

Today, I’ve found a post mentioning an important new feature of the RTW version – calling secure (SSL) services from silverlight 2. This feature mainly allows calling https services while your XAP resides on an http address (kind-a cross domain problem), but more important – silverlight can now pass client certificates to the other server (whether is https or http secured with a smart card).

After putting the clientaccesspolicy.xaml file on the server, we’ve tried again to call a secured server from our client, and voila, it worked !!!

Another security problem solved.