• Binary downloads are available on CodePlex
• Source code on GitHub
• Full release notes can be found here.

Please download the release and report any problems you may find. Assuming no critical issues are found, NLog 2.0 will be released within a month from the RC release.

NLog 2.0 release is focused on adding support for new platforms (Silverlight, .NET Framework 4), improving logging architecture and manageability and addressing most frequently reported user issues.

The following platforms are supported in this release:

• .NET Framework 2.0 SP1 and above, 3.5 (Client and Extended profiles), 4.0 (Client and Extended profiles)
• Silverlight 2.0, 3.0, 4.0
• .NET Compact Framework 2.0, 3.5
• Mono 2.x profile

Read full release notes:
http://nlog-project.org/nlog2-beta1-release-notes

Download Beta 1 bits on CodePlex:
http://nlog.codeplex.com/releases/view/52957

Source code is available on GitHub:
http://github.com/jkowalski/NLog/

Bugs can be reported on CodePlex:
http://nlog.codeplex.com/workitem/list/basic

Discuss on forum:
http://nlog-project.org/forum

Subscribe to NLog RSS feed:
http://nlog-project.org/feed

Follow @JarekKowalski on Twitter:
http://twitter.com/JarekKowalski

• NotImplementedException during SaveChanges() when saving more than 1 entity
• Non-query commands were sometimes cached which was causing update to fail

The code can be downloaded from:

http://code.msdn.microsoft.com/EFProviderWrappers/Release/ProjectReleases.aspx?ReleaseId=4747

The sample can be downloaded from MSDN Code Gallery. It is licensed under Microsoft Public License (Ms-PL). EFQuerySamples includes additional examples of configuring and using the sample provider.

You can download updated bits from MSDN Code Gallery. If you find any other issues, please report them as comments here.

But how do you attach anything to a delegate and Func<T> in particular? Aren’t delegates essentially function pointers?

Well – in .NET each delegate holds information about both the target object instance and the method to invoke on it. This makes it possible to create a tiny wrapper object that would have a function which behaves like Func<T> but holds additional state. Let’s look at a simple wrapper for Func<T> which stores expression:

public class FuncWithExpression<TResult>
{
    private readonly Func<TResult> wrappedFunction;

    public FuncWithExpression(Expression<Func<TResult>> expression, Func<TResult> func)
    {
        this.Expression = expression;
        this.wrappedFunction = func;
    }

    public TResult Function()
    {
        return wrappedFunction();
    }

    public Expression<Func<TResult>> Expression { get; private set; }
}

Let us also define two of extensions methods: one which compiles Expression<Func<T>> and wraps the result with FuncWithExpression<T> wrapper and the other one which extracts the expression from Func<T>:

public static class ExtensionMethods
{
    public static Func<T> CompileAndWrap<T>(this Expression<Func<T>> expression)
    {
        Func<T> compiledExpression = expression.Compile();
        return new FuncWithExpression<T>(expression, compiledExpression).Function;
    }

    public static Expression<Func<T>> GetExpression<T>(this Func<T> func)
    {
        var exp = func.Target as FuncWithExpression<T>;
        if (exp != null)
        {
            return exp.Expression;
        }

        return null;
    }
}

That’s it! (Of course, in real life you would need to provide overloads for more Func<> types, since functions without arguments are not typically very useful). You can now write the code using just Func<T> and still be able to retrieve original expression tree used to compile the delegate:

class Program
{
    static void PrintAndExecute(Func<int> func)
    {
        Expression originalExpression = func.GetExpression();
        if (originalExpression != null)
        {
            Console.WriteLine("expression: {0}", originalExpression);
        }

        Console.WriteLine("result: {0}", func());
    }

    static void Main(string[] args)
    {
        var body = Expression.Add(Expression.Constant(3), Expression.Constant(9));
        Expression<Func<int>> expr = Expression.Lambda<Func<int>>(body);
        Func<int> compiledExpression = expr.CompileAndWrap();

        PrintAndExecute(compiledExpression);
    }
}

This will print:

Read more on http://blogs.msdn.com/adonet/archive/2010/05/10/improvements-to-generated-sql-in-net-4-0.aspx

In addition to regular providers which target databases, it is possible to use wrapping providers which can add interesting functionality, such as caching and tracing. In this post I’m going to explain how to use EFTracingProvider to produce diagnostic trace of all SQL commands executed by EF in Code First.

Setting up EFTracingConnection

In order to use the tracing provider, we need to create a wrapping DbConnection which adds logging every time the command has finished execution. The following helper will set up such connection. As you can see it can log commands to the console, log file or both. Plugging in additional logging mechanisms (such as System.Diagnostics, NLog or log4net) should be trivial.

private EFTracingConnection CreateTracingConnection()
{
    var connection = new EFTracingConnection
    {
        ConnectionString = @"wrappedProvider=" + this.ProviderInvariantName + ";" + this.ConnectionString
    };

    // set up an event which will be raised whenever command has finished executing
    connection.CommandFinished += (sender, e) =>
    {
        try
        {
            if (this.LogToConsole)
            {
                Console.WriteLine(e.ToTraceString());
            }

            if (!string.IsNullOrEmpty(this.LogFileName))
            {
                File.AppendAllText(this.LogFileName, e.ToTraceString() + Environment.NewLine + Environment.NewLine);
            }
        }
        catch
        {
            // catch all exceptions so that we don't pass logging-related failures to user code
        }
    };

    return connection;
}

Object Context Factory

In order to efficiently manage tracing for the application we need to create a central factory class which will create ObjectContext instances for us. This is the place where we will create tracing provider connection and use it to instantiate ObjectContext.

Assuming our Object Context class is called MyContainer, the factory class will be called MyContainerFactory and will have a method called CreateContext, so the usage becomes:

MyContainerFactory factory = ...;

using (MyContainer context = factory.CreateContext())
{
    // use context normally
}

The factory will typically be be long-lived, created at the program startup and stored in a global variable or application state.

Having CreateTracingConnection(), we can now define our factory method by passing instance of the tracing connection to ContextBuilder<T>.Create():

/// <summary>
/// Creates instance of <see cref="MyContainer"/> with tracing enabled.
/// </summary>
/// <returns>Instance of <see cref="MyContainer"/>.</returns>
public MyContainer CreateContext()
{
    return contextBuilder.Create(this.CreateTracingConnection());
}

Simple, isn’t it?

Sample Project

I’ve created a tiny (100 lines of code) sample project which demonstrates this technique. Click here to download it

In the spirit of Code Only the project does not have any non-source artifacts (not even App.config file) and configures everything (model, mapping, tracing) through code:

Here is the output you get when running the application – as you can see all statements are logged to the console – log file is also created with similar output.

Limitations

There is a known issue with this technique where creating databases is not supported on SqlClient provider. Other providers may or may not support this functionality depending on implementation. In general, because of that it is recommended to use unwrapped connections when using DDL APIs (CreateDatabase, DeleteDatabase, DatabaseExists()) as demonstrated in the sample.

Changes in this release since 3.5SP1 version:

1. Upgraded all projects to .NET 4.0 and retargetted assemblies to use .NET Framework 4 Client Profile
2. Removed reflection-based code to invoke CreateCommandDefinition()
3. Moved AspNetCache to a separate assembly (which depends on .NET Framework 4 Extended Profile)
4. Added wrappers for new provider API surface of DbProviderManifest class:
   • bool SupportsEscapingLikeArgument(out char escapeCharacter)
   • string EscapeLikeArgument(string argument)
5. Added wrappers for new provider API surface of DbProviderServices class:
   • void DbCreateDatabase(DbConnection connection, int? commandTimeout, StoreItemCollection storeItemCollection);
   • bool DbDatabaseExists(DbConnection connection, int? commandTimeout, StoreItemCollection storeItemCollection);
   • void DbDeleteDatabase(DbConnection connection, int? commandTimeout, StoreItemCollection storeItemCollection);
   • string DbCreateDatabaseScript(string providerManifestToken, StoreItemCollection storeItemCollection);
6. Wrappers now work in partial trust – check out AspNetCachingDemo
7. Removed Velocity adapter and demo.
8. Recreated sample models using edmx (instead of explicit csdl/ssdl/msl)
9. Removed the need to explicitly install the database in SQL Server – instead using |DataDirectory| and mdf files local to the project.

The sample can be downloaded from MSDN Code Gallery.

Now that Visual Studio 2010 and .NET Framework 4.0 have been released, users of Entity Framework can use POCO objects with Entity Framework without the need for wrapper layers such as EFPocoAdapter. Since I know a number of people are using EFPocoAdapter in their production applications and it is not supported, I recommend they migrate to using native POCO support in EF v4.0 which is the supported way of using POCOs from now on.

This post will highlight the differences between EF and EFPOCOAdapter, which you must keep in mind when migrating your code base.

Note that this list is not guaranteed to be exhaustive and does not imply that there are no other differences.

Change tracking differences

Entity Framework v4.0 supports 3 different "flavors" of POCO objects:

• Basic (plain) POCOs
• Lazy loading POCO proxies (non-sealed class, with default constructor and all navigation properties marked as virtual and overrideable)
• Change tracking POCO proxies (non-sealed class, with default constructor, all properties marked as virtual and overrideable and all collections using ICollection<T> types)

EF will enable particular feature (such as lazy loading and change tracking) if all required conditions have been met and there is no mechanism to explicitly request a particular type of behavior for each property. If the conditions have not been met, EF will fall back to plain POCO behavior.

EFPocoAdapter provides more fine-grained approach – you can set a change tracking mode (Snapshot, Proxy, etc.) for each property individually in CSDL by using objectmapping:ChangeTracking attribute. This is not supported by EF – the user needs to choose between one of the three flavors of POCO and mark properties of the entity accordingly. This ability to explicitly specify a tracking mode for every property might be implemented in future versions of EF.

From the performance standpoint, using change tracking-enabled objects is recommended, but doing so is not always possible, especially when you have code that expects concrete POCO types to be in use (such as WCF serialization). To learn more about this issue and possible workarounds check out this blog post: http://blogs.msdn.com/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx

Value objects

EFPocoAdapter supports objects which are immutable (can only be constructed, but not modified) and semi-mutable objects when certain properties are read-only and must be initialized in the constructor while some are read-write. Below is an example of an immutable value object:

public class Category   
{   
    public Category(int categoryID, string categoryName)   
    {   
        this.CategoryID = categoryID;   
        this.CategoryName = categoryName;   
    }   
  
    public int CategoryID { get; private set; }   
    public string CategoryName { get; private set; }   
}

EF v4.0 does not allow this directly (it always requires a default constructor without parameters and property setters to be there), but you can persist value objects and read them back by having setters which are non-public (EF will still be able to access them in full trust, but your application will not). You just need to add a non-public default constructor, as in the following example:

public class Category
{
    private Category()
    {
        // this constructor will be called by EF
    }

    public Category(int categoryID, string categoryName)
    {
        this.CategoryID = categoryID;
        this.CategoryName = categoryName;
    }

    public int CategoryID { get; private set; }
    public string CategoryName { get; private set; }
}

This approach has some downsides, because there is no validation happening when object is hydrated from the database (as it is bypassing the construction logic), but you may argue that this is not so bad since the object must have been validated before it was persisted.

Also note that you will need to switch from structures (C# struct) as a representation for value objects to classes, because the former are not supported in EFv4.

Lazy Loading

There are differences in the way lazy loading is implemented. In EF v4.0, collection properties with lazy loading need to be virtual, in POCO adapter they do not but it they have to be ICollection<T> or IList<T>. EFv4 supports lazy loading of concrete collection types (such as List<T>) while POCO adapter does not.

This is an example of a class which has Products property which can be lazy-loaded in Entity Framework:

public class Category
{
    public int CategoryID { get; set; }
    public string CategoryName { get; set; }
    public virtual List<Product> Products { get; set; }
}

Lazy-loaded properties of type ICollection<T> need to be marked as virtual to get lazy loading

Shadow state

Because of the way POCO adapter is implemented, it is also possible do omit certain properties (such as auto-generated GUIDs, etc.) from the POCO model but still have them in CSDL model. This is not something that’s possible in EFv4, so you need to add the properties to your domain classes. As in the case of value objects, properties can be private, but EF needs to be able to see them in order to load your model.

API Differences

The following table lists EF POCO Adapter classes and their EF v4.0 equivalents:

Method names of POCO adapter classes typically correspond to method names in Entity Framework v4.0, but since POCO adapter was created at the beginning of EFv4.0 there can be some differences you will need to fix during the migration. Since POCO adapter is generally a subset of EF you should be able to easily find corresponding methods and properties, except:

• EFPocoContext.EnableLazyLoading – use ContextOptions.LazyLoadingEnabled
• EFPocoContext.ConvertProxiesToPoco() and EFPocoContext.ConvertPocoToProxies()
• EFPocoContext.IsProxy()

I’m hoping these hints will be helpful to folks porting their apps to use POCO support in Entity Framework 4.0. If you have any further questions, feel free to ask them here.