EF 4 Error – Mapping and metadata information could not be found for EntityType

Yes, Entity Framework (EF 4) is great and finally makes EF ready for prime time with various much needed improvements, including the ability to use POCOs.

However, the one thing that you may not like about it is that pesky error that you most likely to bump into while wiring things up. That one generic unhelpful error which says : Mapping and metadata information could not be found for EntityType …

This error is an EF catch all when trying to connect your POCOs to the Entities model so the reason why it’s annoying is because it could be literally anything.

]9 out of 10 times one of these should solve your problem:

1)Entity is missing from the Entities Model : it seems quite obvious, but when you’re working back and forth with database and code it becomes easy to forget that there is actually a middle man there that you need to keep updating. Remember, your code does not work with the database, it works with the Entities Model so anything you change in or add to the database needs to be reflected on the Entities Model.

2)Mispelled property : This is the most frequent mistake. Check that the name of every property on your POCO matches the column name on your Entities Model. Note that EF is case-sensitive so pay attention to that. Also note that you should be matching names to the Entities Model not your database as they could differ depending on how your generated your edmx file.

3)Missing property : quite self-explanatory. Make sure you include everything that shows up on your Entities Model for the Entity you are trying to map, including any data relationship objects (though those should hopefully throw you a more specific exception, but better safe than sorry)

While EF is sensitive to other things such as Type mismatch, those actually do give you clearer errors. For instance, if you map a “money” SQL data type to anything other than decimal, EF will give you a clear error message saying that the types don’t match, so hopefully it shouldn’t be too hard to figure those out and by then you’re past the generic error obstacle.

Why var can be dangerous in C#

While code reviewing the other day I found something similar to the following piece of code. Taking the subject of this post as a hint, see if you can find out for yourself what is wrong with the following code:

public static class HtmlHelperExtensions
        public static string Example(this HtmlHelper helper)
            var currentControllerName = helper.ViewContext.RouteData.Values["Controller"];

            if (currentControllerName == "Home")
                //do something

Have you figured it out?

The problem is that what’s happening in that if is an object reference comparison not a value comparison as it’s intended to. The reason for that is because helper.ViewContext.RouteData.Values[“Controller”] returns an object so when we use the == operator to compare it to a string it will, as you may know, compare that the object references are the same rather than verify if the value returned by our expression is equal to “Home”.

While this can be a common mistake and the use of var is not actually causing it, I’m blaming it on var only because had the developer not used var the code just wouldn’t compile. The compiler would force you to make the explicit cast to string and this obscure bug just wouldn’t exist. Of course nothing stops the developer from doing a direct comparison like this, if (helper.ViewContext.RouteData.Values[“Controller”]) == “Home”), however that for me is just reinforcement to say another point I make which is that you shouldn’t chain too many calls in one line of code and should always store values in variables for the purpose of making your code clean and debug friendly.

Now, I’m not an advocate against var, I actually like var, however, this is just an example of how you should always put thought into your choices rather than using something mindlessly just because it’s available (or just because Resharper tells you so, for that matter!). Code is all about choice, so make sure there is reasoning behind yours.

IoC in ASP.Net MVC 3 and the IDependecyResolver – Ditch or Dig?

right, folks, as some of you may have noticed ASP.Net MVC 3 has introduced a layer of abstraction to configure IOC containers.

While this is a good thing and definitely a step in the right direction the folks at Castle Windsor, for example, highly discourage it at the moment because the new interfaces lack support for releasing components which can lead to memory leaks if not properly handled. On a web scenario, most likely this isn’t a problem since you should be wiring your components with a PerWebRequest lifecycle or whichever is the equivalent in your IoC of choice; however, I agree with the folks at Castle Windsor that you shouldn’t use an incomplete API.

Furthermore, I may be alone in this but I think the new way is actually more work and more complicated. In the new way you would be implementing an IDependencyResolver which contains methods for resolving singly registered services and multiply registered services. Essentially the first is a one to one mapping when there is only one acceptable implementation of a service, for instance if you have an ICustomerRepository which is satisfied by a CustomerRepository instance, whereas the multiply registered services is when an interface has a variety of matching services that should be instantiated because they are all valid and used; think something like Model validation which may have many objects all doing different kinds of validation and they all implement the same interface so they all need to be instantiated and made available for processing.

Besides having to understand this difference and how to handle it properly with your IoC API you have to remember to return null if the dependency can’t be resolved. In addition you may want to play with IControllerActivator and IViewActivator which are mechanisms that you can use to determine the lifestyle of the objects you create, more specifically, Controllers and Views respectively, however, again, these are still not complete as they lack release mechanisms and again are not very straightforward.

Now contrast that to inhering from the DefaultControllerFactory, implementing the Create and Release methods which are usually just two or three lines of code and adding a line of code in Global.asax to register it with the MVC engine.

While I’m always willing to change mentality and approach I think it needs to be justified in terms of improving some factor of either quality or productivity and unfortunately, while I think Microsoft has taken the right step, there is still a mile to walk before these new abstractions can become the norm.

Changing NuGet packages folder path

One feature of NuGet that it’s not very well documented is the ability to change the path of the packages folder.

All you need to do really is create a file called nuget.config at the same level as the solution file with the following content:



In this example I created a library folder which sits one level down from the solution file. Notice that the repositoryPath element only takes relative paths. Absolute paths are not supported (for good reason, if you think about it, since you want your project to be self-contained and not tied up to your machine’s folder structure).

The only other thing you need to do is move the repositories.config file to your custom package folder and edit the path inside to point to your project file.

Apparently NuGet hasn’t emphasized this because they’re looking into a way to work this into the UI, but until then you have to do things manually.