Tuesday, May 6, 2008

ADO.NET Entity Framework Beta 3

I started working on a new application for a client this week that is going to use the ADO.NET Entity Framework. Since it is not final release yet I had to download and setup the ADO.NET Entity Framework Beta 3. It wasn't too bad to get installed but I did run into a few issues along the way that I thought I'd share to save you some time if you end up having to do something similar.
I ended up having to install the following in this order:
ADO.NET Entity Framework Beta 3
ADO.NET Entity Framework Tools Preview can only be installed if a necessary Visual Studio patch is installed.
ADO.Net Entity Framework Tools Dec 07 Community Technology Preview
At this point I had everything installed so I could add a ADO.NET Entity Data Model to my project.
Another good resource for ADO.NET related info can be found here:
One other thing I did notice when working with the ADO.NET Entity Data Model was that it all seemed to be very straight forward to setup and test if your UI and data access were in the same project; however, I found that when setting up a n-tier architecture I ran into some annoyances. The data layer I setup contained my ADO.NET Entity Data Model and it automatically creates an App.Config file with the necessary connection information and it creates the .csdl file, .ssdl file and .msl file in the data layer's /bin folder; however, when you add a reference to your data layer from your UI or business layer it does not automatically copy the connection string information into your Web.config file and it does not copy the .csdl file, .ssdl file and .msl file into the web application's /bin folder. So I ran into error messages until I finally figured out was going on.
To work arond this I created a Config/ConnectionStrings.config file and copied the connection information from the App.Config file into the new config file and had the Web.config reference the new config file. Then I copied the .csdl file, .ssdl file and .msl file into the web application's /bin folder. Once I did this I was able to use the ADO.NET Entity Data Model as my data access and isolate the data access to the data layer. The issue with this is that if you change your model you have to manually copy the files to the web application's /bin folder again. I'm hoping that I'm either just not doing something right or this is just because it is still Beta and will be easier in the final release.
I also found that quite a few code samples I came across had the Using ... End Using notation around their entity code; however anytime I returned a generic list, for example IEnumerable(Of T), from the data layer to another layer the connection would be lost and I would get an error that said:
A connection string must be set on the connection before attempting the operation.
It wasn't apparent to me what the problem was initially but then I took out the Using ... End Using notation and everything worked perfect. The End Using code from the code samples was forcing certain objects to be destroyed, including the connection.
I've tested retrieving data, adding data, deleting data, updating data, filtering data using standard LINQ syntax as well as Lambda Expressions and binding IEnumerable(Of T) data to a GridView.
So aside from the minor annoyances I ran into along the way I now have a working project that uses the ADO.NET Entity Data Model.