0

I have an EF Code First project that I compile as a C# class library dll, and I have several other projects that create executables targeting my database that keep a reference to this project. My question is, do I have to keep redundant copies of app.config in each project that uses this DB Context? I've also got separate references to Entity Framework in each application project, which appears to be necessary, even though I had hoped to encapsulate that in this one project. (I suppose I could still do that if I exposed a web service or something, instead of making all my EF classes public.)

Do I have to specify the connection string in each executable project's app.config? Does the config file for the dll project get overridden? I've got a funny feeling I'm missing something.

I did see this answer allowing inclusion of an external configuration, but it appears only to affect the appSettings section of the config file. Right now all my config files are app.config instead of web.config since my apps are all either console, desktop, or service applications, but I'm assuming the same principles apply to web apps referring to a single class library.

Update: Would it make sense to have a single app.config file which included named connection strings for each of my databases, and have each executable project point to this one via Add Existing Item (as DLeh suggests below)? If I do that, can I then use a Settings file in each executable to allow overriding which connection to use without rebuilding the project? This would reduce the number of build targets considerably I would think; otherwise I'd have the Cartesian Product of DB instances and executables.

Community
  • 1
  • 1
Jay Carlton
  • 1,118
  • 1
  • 11
  • 27
  • we have a similar situation. we have a shared `ConnectionStrings.config` that we have in our solution. When we have a new runnable project that needs those, we do `Add Existing Item ` > then click the dropdown and do `Add As Link` so that it doesn't dupe the file. You could do the same with the whole `app.config` file – DLeh May 28 '15 at 18:01
  • @DLeh: Thanks, that's probably going to be part of the solution. The other trick is managing multiple potential DB connections (e.g. LocalDB, test DB instance, and production). I found a trick involving copying one of several config files on a per-target basis, but I don't really like having to do separate builds for each database if all I want to change is the connection. See http://stackoverflow.com/questions/8082662/how-to-select-different-app-config-for-several-build-configurations – Jay Carlton May 28 '15 at 18:15
  • yeah we have a similar problem. we have a jenkins server set up that runs those for us, but i ended up writing a tool to help me change db connections easily. – DLeh May 28 '15 at 18:28

1 Answers1

0

Not necessarily, depending on what I want. I can share a single app.config file with all my executables, put multiple connection strings in that one, and choose the connection I want at runtime. Alternatively, I can set up separate builds for each deployment scenario, but this seems expensive in terms of compile time and disk space if the only difference is a couple of configuration strings. It looks like the connection string that counts is the one in the exe's app.config, not the app.config in the class library dll project.

Another trick is the configSource attribute. See this Code Project article.

Jay Carlton
  • 1,118
  • 1
  • 11
  • 27