1

Regarding this answer: https://stackoverflow.com/a/10772137

It seems Entity Framework is taking the connection string property from the startup project's config file, rather than from the referenced project's config file.

Why is this? Is that a (somewhat weird) convention? Is there any reasoning behind this decision?

Or is it just not possible for a DLL to have an accessible config file?

Community
  • 1
  • 1
Letterman
  • 4,076
  • 5
  • 29
  • 41
  • by design. "original" config is not included in the startup project so compiled – Alexander Taran Dec 26 '13 at 10:46
  • Some of the rationale is explained in [C# DLL config file](http://stackoverflow.com/questions/594298/c-sharp-dll-config-file). Yes it's possible, no, it's not advisable. If you can explain why you think you need this, perhaps some more specific answers can be given. – CodeCaster Dec 26 '13 at 10:48

1 Answers1

3

Why is this?

A config file is somewhere for end use administrators to configure the application. Having multiple config files quickly becomes confusing unless they have very clearly separated usage.

Connection strings and similar configuration items always go into the .exe.config (or web.config) file, therefore this is where administrators would expect to find and maintain that information.

Thus there is nothing weird about this. The only weird thing is the EF tooling generating an app.config in a class library project (but then where else to put it: there may not be an executable project in the solution: or there could be multiple).

Or is it just not possible for a DLL to have an accessible config file?

You can use the System.Configuration assembly's types to open and process an arbitrary file as a configuration file, so it is possible. But none of the assumptions of a central configuration (eg. passing the name of a configuration string – rather than the configuration string itself – to the EF constructor) will work. See this answer for more information.

Community
  • 1
  • 1
Richard
  • 106,783
  • 21
  • 203
  • 265