我刚刚继承了一个非常古老的ASP.NET 2.0 Web应用程序。
在应用程序中它有几个支持类库项目。在DataAccess类库中，是一个app.config（和setting.settings文件），其中包含一个名为ConnString1的连接字符串。
我一直认为.DLL没有app.config / setting.settings文件（或者至少你可以包含它们但不会被使用），所以这让我很困惑。< / p>
web.config还有一个名为ConnString1的连接字符串，它具有相同的服务器登录凭据，但具有不同的服务器名称。
当我从Visual Studio DEBUG运行应用程序时，它使用位于app.config / settings文件中的连接字符串，而不是web.config / machine.config中定义的连接字符串。
我认为.DLL不会这样做，而是使用web.config？
但是，当我将此应用程序以RELEASE模式推送到我们的生产服务器（在测试网站中）时，它似乎在web.config中使用了正确的连接字符串。
任何人都能解释一下吗？
答案 0 :(得分：2)
必须有一些令人困惑的事情让您认为正在使用该DLL的一部分的配置文件 - 而不是应用程序（入口点）的配置文件（yourapp.exe.config或web.config） 。也许conn字符串在某处被硬编码以用于调试模式，例如通过“#if DEBUG”预处理程序指令使用条件编译（因此，可能在您的解决方案中搜索“#if DEBUG”以查看是否发生了这种特殊情况）。
MSDN article about app settings
请参阅“在设计时创建应用程序设置”一节中的黄色“注意”：“因为类库没有配置文件模型，所以应用程序设置不适用于类库项目。”
答案 1 :(得分：2)
我发现了这个问题：
在上面的例子中，我使用web.config / machine.config来设置应用程序的连接字符串。
如果未在web.config中定义连接字符串，则默认为machine.config。如果未在machine.config中定义连接字符串，则它将使用.dll中的app.config设置。
重要的是要注意，将连接字符串放在machine.config中，必须在正确的Framework / CONFIG中定义。
在我的开发机器上，连接字符串没有在web.config中定义，而是在environment.config中定义，但在Framework64 / CONFIG中 - 但是，应用程序是以32位编译的，因此，原因使用没有在其中定义连接字符串的Framework / CONFIG，并使其默认为类库中的app.config。
我希望能解释一下吗？
答案 2 :(得分：1)
必须在可执行配置文件中指定所有配置设置。对于Windows和控制台应用程序，它是app.config，对于Web项目，它是web.config。
库可以指定配置设置，但您必须将设置复制到可执行文件的配置文件中，以便应用程序能够读取它们。
答案 3 :(得分：0)
Web.config。 Web.config是IIS的必需配置文件，用于配置它在Kestrel之前作为反向代理的行为。如果要在IIS上托管它，则必须维护一个web.config。
对于与IIS不相关的其他所有内容，请使用AppSetting.json。 AppSetting.json用于Asp.Net Core托管。 ASP.NET Core使用“ ASPNETCORE_ENVIRONMENT”环境变量来确定当前环境。默认情况下，如果您在不设置此值的情况下运行应用程序，它将自动默认为生产环境并使用“ AppSetting.production.json”文件。通过Visual Studio调试时，它将环境设置为“开发”，因此它使用“ AppSetting.json”。请访问此网站以了解如何在Windows上设置托管环境变量。
App.config是.NET使用的另一个配置文件，主要用于Windows窗体，Windows服务，控制台应用程序和WPF应用程序。当您通过控制台应用程序app.config启动Asp.Net Core托管时。
配置文件的选择取决于您为服务选择的托管环境。如果使用IIS承载服务，请使用Web.config文件。如果使用任何其他托管环境，请使用App.config文件。 参见Configuring Services Using Configuration Files documentation 并查看Configuration in ASP.NET Core.