Monthly Archives: February 2012

Mapping private/protected/… properties in Entity Framework 4.x Code First

More than a year ago I was blogging about how to map private/protected/… properties in Code First CTP4 for the time being. Well it a long time and a lot of changed. The code there isn’t absolutely up to date with current Entity Framework 4.3.

Although you can go raw and create the expression tree from i.e. string yourself (Mono.Linq.Expressions can be quite handy) it’s not nice and more importantly it’s not strongly typed. If you don’t want to use data annotations or couple your configuration classes into entity classes you’re still not lost. In the above linked post in comments Drew Jones came with a nice idea.

You entity classes will be partial classes and somewhere else you’ll create second part of that class with the expressions needed to express the properties. Let’s take a look at example (you can adjust access modifiers according to your needs and structure).

public partial class FooBar
{
	private int ID { get; set; }
	private string Something { get; set; }
}

public partial class FooBar
{
	public class PropertyAccessExpressions
	{
		public static readonly Expression<Func<FooBar, int>> ID = x => x.ID;
		public static readonly Expression<Func<FooBar, string>> Something = x => x.Something;
	}
}

And now in mapping you’ll just use the expressions.

	.Property(FooBar.PropertyAccessExpressions.ID);
	.Property(FooBar.PropertyAccessExpressions.Something);

Nice isn’t it? It’s separated (kind of – you can’t have entity classes in one assembly and the expressions in other) and it’s strongly typed.

log4net dependencies problem – solved

OK, following log4net’s versioning scheme in NuGet package wasn’t a good idea. In version 1.2.11 the new keys were used and I used this as a fresh start. I didn’t realized that thanks to semantic versioning everybody will be updated to latest version and dependencies will be broken. My fault. :-?

If you read my previous log4net post there’s a solution with modifying package.config file, but… So to fix it package owners were forced to repack the dependencies to be =. Not good.

So today I pushed version 2.0.0, which is actually 1.2.11 with new keys, and 1.2.11 was removed. So there’s now on NuGet the new major version and dependencies need to be explicitly stated to be compatible with it (again, it’s 1.2.11 with new keys).

Fire is quenched, hopefully.