Not the Way I Intended to Spend My Evening (Fun with EF Code First Development)

I decided to spend a bit of time last night working on my weight loss website.  Got my development environment started up, and launched the app to do a quick run-though to see where I’d left off, and… The app craps out on accessing the database.  Great!  I didn’t remember if I had changed anything since the last time I’d done some development (a bit over a week ago), and now it’s forgotten how to connect to the database.  Time for a bit of documentation spelunking!  Yay…

Code First development with Entity Framework will automatically create a database, all of the tables defined by your POCOs, and take care of the foriegn key relationships.  So in theory, it should be as simple as starting your app, and Bob’s your uncle– Database and tables all set up with no extra configuring on my part.  The only problem was, I hadn’t set up a database connection for EF in the web.config file, so the system did it for me.  Not too much of a problem, since I’m in early development anyway– It doesn’t really matter where stuff gets stored.  However, I knew I would want to be able to change that later.  When I go live with the site, I’ll want to be able to set what database the app is pointing at.  As a quick exercise, I added a SQL Server file to the project, and then changed the connection string to point to it.  Apparently, that was the last thing that I’d done last time I’d worked on this, because I don’t remember having any problems before last night.

Another problem I had early on with the database has been with ASP.NET’s authentication system (Membership, Roles, and all that jazz).  While it’s great that Microsoft has moved towards “convention over configuration” for ASP.NET MVC, there’s still a few holdovers from the old way of doing things.  If you use the default authentication, the system will automatically set up a database for all the user data.  In my app, the default was a named database in SQL Express (installed along with Visual Studio).  Again, that’s ok– at this point of development, I’m not all that concerned about where it’s getting stored.  BUT– by default, it’s a DIFFERENT database from what EF creates!  Right now, I’ve got three little databases that are all associated with this app– two created by default by ASP.NET (one for authentication, one for EF), and the one I created in the project directory.  Obviously, one is my fault– the one I created as a test, but I fail to see why Microsoft’s stuff should be creating so many separate databases by default!  Perhaps establishing a single connection string at the beginning of the project that all of these groovy services would then use would be helpful to hapless developers like me.  What do you think, Microsoft?