Wait! which config file? (Entity Framework Connection String)

Question

So, I created my entity model in a separate class library. I had to add the connection string to the app.config file of that class library. Then I added a ref for that project in my web application. I added the same connection string in the web.config of my web application thinking this is where Entity Framework will be reading the connection string from.

Everything was fine up until I deployed my web app. When I deployed I change the connection string in the web.config (not app.config of the class library) and I started getting errors. After doing some research I found out that the connection string in both web.config and app.config must match!!

This is just dumb! Every time I need to deploy my web app to a different environment I must go back and modify the connection string in the app.config file and then recompile my class library project just so it can get the refreshed connection string?

Has anyone found a better way of doing this? I mean, I cant be only person who thought of putting the entity model in a seperate assembly.

Possible Solution (if you are using EF 4.1): Since the only reason why we need to have app.config inside a class library project is for the EF designer. If we ditch the designer approach and go with Code-First (EF 4.1) you will not need to have an app.config file for your class library project.

Answer 1

We ran into the same situation. I've asked each developer to only ever compile the EF assembly with the first connection string selected.

This way, when deployed, only one connection string is needed in the web.config.

Eventually, if each development machine and deployment server has the correct connection information (for that machine) in the first (and hopefully only) connection string (i.e., not ConnectionString4), life is easy.

Basically, extra connection strings are added by the designer to the dev connection string when the default connection string (latest selected) can't connect.

Also, there's no reason to feel bad about putting the data layer into a separate assembly. Sometimes this is preferable.

Finally, it's pretty important to make sure the config file that contains the connection string is not hooked to source control -- the connection string is often localized and will cause the "multi-connection-string-issue" in EF and LINQ to SQL if it keeps getting overwritten with bad values every time you update your project from source control.