ApplicationSettings across libraries

Question

I'm trying to abstract out all database code into a separate library and then use that library in all my code. All database connections are done using typed TableAdapters that I create by dragging and dropping in datasets in VS2005, using a connection string from the appSettings.

The problem that I haven't been able to solve is that .Net doesn't propagate the libraries appSettings to the other project that's using it.

In short, I have a database layer library, MyProgram.DbLayer, which is used by other projects such as MyProgram.Client etc. When I had all the datasets in the .Client the connectionString was in MyProgram.Client.exe.config so that I could change it after build. When I moved it into the MyProgram.DbLayer that setting isn't avaliable to me after I build the binaries.

EDIT: This seems to be a more general issue with ApplicationSettings.

What I noticed was that if I manually add a setting only used in a library it will be properly read. The only thing I need now is for the setting to be automatically included in the .config file as well.

Answer 1

AppSettings/ConnectionStrings will always be read from the currently running app pool.

By this I mean:

If I have A.exe which has a class DAL.cs. DAL.cs reads a connection string from config, and it returns "abc" as expected.

I then move DAL.cs to its own project, and thus, its own assembly. I can still have it call the connection string from app.config, however, I will need to "host" the assembly in a running application, and add the connection string to that applications app config. So, I create a new app.config and specify the connection string "xyz" in it, when it runs, it runs as expected.

Now, if I change the reference in the A.exe project to use the new DAL.dll, what connection string do you think it will have? "xyz"? Nope! It will use the "abc" as it did before because that is still configured in the application configuration file for A.exe.

I know this works because I used shared DAL code across many Windows and Web applications.

If any of this is unclear, or does not help your problem, please let me know by commenting on this answer.

Update following comment from OP

By "host" I mean an application that is calling on the common code. This can be a Windows or a Web application, basically it is the application context.

You will need to create entries in the configuration files for each application that uses the common code. If I misunderstood your original question (entirely possible, it's been a long day!) and you wish to centralize the configuration as well, then you would need to:

• Create some form of centralised storage (be it XML, DB, whatever).
• Enhance your common code to have default values to enable it to connect to the centralised storage.
• From there, the code can then configure itself, based on the information in the configuration store.

Hope this helps :)

Answer 2

If I understand your problem correctly, it sounds like you'll need

1.) A common application context for all data access calls

or

2.) A different way of accessing configuration settings

1: Wrap your data layer within a service that runs under a single context (IIS, Windows Service, etc)

2: Don't use the Configuration Management mechanism that you are supplied. Instead use property files in a specific location.

Don't forget though that the configuration settings cascade from different levels. For example...if you add a setting in machine.config, then every application running on that machine will use that setting unless it is replaced at a lower level...That may be a good way to setup a standardized setting within your configuration files.