Why is app.config working abnormally?

Question

My problem is solved but I don't quite understand the solution and why it worked. I made a class library "Business Layer" inside a solution which also contains a Windows forms project (C#). Within the class library I put an app.config file and defined a connection string inside it, which I used in SQL-connection code in the business layer. Then I called the database logic in the Windows forms application, but the project failed at the connection string part (ie, it returned null). However, when I copied app.config to the application project it started working. Why? Why is it that if I am using all database code in the business layer that pasting the code in the application project worked?

Code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
  </configSections>
  <connectionStrings>
    <add name="ConnectionString" connectionString="Data Source=HOME-PC;Initial Catalog=LMS;Integrated Security=True"
      providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

getting:

string conStr = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString.ToString();

Answer 1

You are using the following code in your program:

string conStr = ConfigurationManager.ConnectionStrings["ConnectionString"]
    .ConnectionString.ToString();

So, what does this do? Why is this important?

ConfigurationManager will look for the app.config or web.config (if you are making a web site) that corresponds to the running program . For example, if you have a program called "MyCoolProgram", you would have two output files called "MyCoolProgram.exe" and "MyCoolProgram.exe ". ”的输出文件。

It's because of this naming structure that the ConfigurationManager is able to work.

But you already made an app.config, right? You made one in your referencing dll project. Why do you have to make another app.config with the same values?

So let's add in another project to our example. So far our example solution looks like this:

• MyCoolProject (exe)
• CommonLogic (dll)

If both projects have their own app.config file, the files listed in MyCoolProjects' bin folder would look like this:

• MyCoolProject.exe
• MyCoolProject.exe.config
• CommonLogic.dll

So first, where is the config file for CommonLogic? It's not there. By default, a class library's config file is not copied over with the dll file, but you can see it still exists in CommonLogic's bin directory.

Second, so let's say that you do copy over CommonLogic's config file. You will have a file called CommonLogic.dll.config in MyCoolProject's bin directory. However, with "MyCoolProject.exe.config" empty, your code still can't find the connection string. It's strange because,

1. The connection string is set (only) in CommonLogic.dll.config
2. The code that is trying to get the connection string is from CommonLogic

So what gives?

Remember what I said before: ConfigurationManager will look for the app.config that corresponds to the running program , not the assembly that the code was ran from. No matter where your code is, the Configuration Manager is going to look at "MyCoolProject.exe.config" for any values. It's not going to look at anything else. For all intents and purposes, it doesn't even know about any other libraries or config files.

This means that you need to put your connection string (preferably exclusively) in the program that will be consuming the referencing library.

The class library should not be in charge of setting the connection string, that should be up to the program that uses it.

Answer 2

when I copied app.config in actual application project too then it started working, why ?

Because app.config is for the application , not the library . VS just gives you an app.config for a library to show you what should be put in the application configuration file.

It's perfectly reasonable to assume that a library can be used in multiple applications with different configurations, so tying the configuration to the library would make it harder to separate the configuration between applications.