Reddybrek.com

There is already an open DataReader associated with this Command which must be closed first

Filed under C# , code first , entity framework

I was working on one of my Entity Framework Code First websites the other day when I noticed the following error being returned to me:

There is already an open DataReader associated with this Command which must be closed first

Doing a few searches online I could see some of the solutions were to include the parameter 'MultipleActiveResultSets=True' in your entity framework setting in the web.config. However, when I checked my web.config to look for this setting I noticed that I did actually have it all setup as expected.

Doing some more digging around I noticed that the cause for this issue is down to an issue with deferred execution in some of my queries.

The solution was to add a simple .ToList() at the end of my query.

A simple fix but one that drove me nuts for a while!

How to force your database name using Entity Framework migrations in a multi-project solution

Filed under C# , code first , entity framework , migrations

If you're using Entity Framework migrations in a multi-project solution you might have noticed that when you run the 'Update-Database' action your database was given the name 'yourdatabase.Data.DataContext'. Some people don't mind this default naming scheme but I want to call my databases something a bit cleaner.

My typical MVC solution contains many projects to help keeps things separated. My database code is in my 'Data' project but my web.config file handling my connection string is usually contained in my 'Web' project. I noticed that even if I have given my database a name in my connection string this was not being picked up by the Entity Framework Migrations code.

Luckily all you have to do to force entity framework to use the database name you want is put the database name into your Context file. For example:

public class DataContext : DbContext
    {
        public DataContext() : base("DatabaseNameHere")
        { }

        public DbSet Table1 { get; set; } 
        public DbSet Table2 { get; set; }
    }

How to avoid the entity framework migrations error: 'Could not load file or assembly or one of its dependencies.'

Filed under C# , code first , entity framework , migrations

I've been using Entity Framework migrations for a few weeks now and I'm having a great time with. However, I've notice that every now and then Entity Framework throws an error when I try to run the 'Update-Database' command.

Whenever you get a message 'Could not load file or assembly or one of its dependencies. The system cannot find the file specified.' there are a few steps that I've noticed you can do to help work around this type of error.

• Step 1: Firstly, ensure that your models and any relationships that you've setup are correct. Sometimes this error means that you have incorrectly setup a join or a relationship previously setup is broken. At present the error messaging returned by migrations is a tad lacking and it returns the above error for broken model relationships.
• Step 2: If you change your models I find that unless I edit my Data Context file I get this error. My solutions usually contain many projects. I don't know if that is the reason I get this error message but if I update one of my models without altering the context file migrations continues to return the above message for me. If I don't need to alter the context file (usually I don't as I've just added a new column) then simply pressing space and re-saving the context file does the trick.
• Step 3: Check your database isn't 'blocking' migrations from running. I ran into a few occurances where I would have manually deleted my database and occasionally this would stop migrations from creating a new database. This is a simple fix. Just right click on the Databases heading in SQL Server and click on 'refresh'. If a refresh doesn't solve the issue, try closing SQL Server Management Studio down and restarting it again.
• Step 4: Clean your build history and try a rebuild before running 'Update-Database'.
• Step 5: Lastly, try forcing code first to run by using '- Force'. For example 'Update-Database -Force'. This command is also useful for telling migrations to carry out a task that would result in a data loss.

If you continue to get the error message mentioned above then the issue is nearly always down to your code. Recheck it and try again. I'm sure as Entity Framework Migrations matures they will be able to return better, more meaningful, error messages.

Entity Framework v4.2 upgrade not working

Filed under C# , entity framework , nuget

This particular error caused me some headaches so I decided to blog about it in the hope that it'll help some other poor soul! I have a pretty standard MVC 3 project that uses Entity Framework Code First for handling the database side of things. I decided to update my project to ensure it was using the latest version of all of the packages in use on my project (ninject/entity framework/etc). This particular project was using Entity Framework v4.1, which I had previously updated using NuGet without any problems, so I decided to download and install the latest version from NuGet - ver 4.2.

The Problem:

I know after installing any new version of Entity Framework it's always wise to restart Visual Studio and do a clean rebuild of your project but when I went to run this project locally it threw up the following error:

Could not load file or assembly 'EntityFramework, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

It was fairly obvious that my project was looking for the wrong version of EF but I couldn't tell why. I went looking for any hard coded mention of EFv4.1 but nothing was returned. Next I did some searching online but nothing seemed to match my particular error. I took a closer look at the detailed error log and noticed it was looking for the entityframework.dll file but was not finding it.

The Solution:

I took a look in the 'Packages' folder that NuGet installs the files to. I could see 2 Entity Framework folders. One folder was for the older v4.1 and one was for the new v4.2. I took a look inside the v4.2 folder  and could see the dll files in there so I knew the files had downloaded. Then I took a look in the v4.1 folder and noticed that the folder structure was different.

• I went back into the v4.2 folder (Packages\EntityFramework.4.2.0.0\lib\) and could see a folder called 'net40' that contained the dll files.
• I cut the 2 files out of there and placed them into the 'Packages\EntityFramework.4.2.0.0\lib' folder (up 1 folder level).
• I went back into Visual Studio, did a rebuild and everything went back to work for me.

Reading back over this post I can't believe how easy and simple the fix was. Up until now NuGet had always worked so it never crossed my mind that it would have botched the update. Hopefully this solution will help you out if you see that dreaded error message. Fingers crossed NuGet won't do anything like that again to me.