我经常使用的VS解决方案由一个可执行项目(控制台应用程序、Web应用程序)和许多类库项目组成，这些项目都由可执行文件引用。

在处理nuget和安装包时，通常会为每个项目创建一个app.config文件，通常只包含一个绑定重定向列表，用于合并引用程序集的版本。有时会有一些第三方库特定的内容(比如实体框架配置部分)，但现在我们把它放在一边。

当我构建解决方案并使用主可执行项目的二进制文件时，我看到构建输出中的所有类库项目程序集以及相应的*.config文件(在构建时，app.config文件重命名为AssemblyName.config)。

在启动主可执行文件时，类库程序集的配置文件会有任何效果吗？或者只是可执行文件的app.config文件在这种情况下起作用？如果在某些类库项目上设置了一些绑定重定向，而在主可执行项目上设置了一些不同的绑定重定向，那么会怎么样？这些重定向是如何组合的，哪些是优先的？

我试着在网上研究这个问题，从我读到的内容来看，不可执行程序集的app.config文件似乎是无用的(关于绑定重定向)。有人能证实这一点吗，或者就这个话题再详细阐述一点？

如果是这样的话，如果这些app.config文件只包含绑定重定向，那么在类库中由nuget创建这些app.config文件实际上是不可取的吗？我觉得nuget不应该为类库项目创建那些绑定重定向，因为它只会增加对实际应用的设置的混淆。

我在这个主题上发现了这些现有的堆栈溢出问题，但它们被接受的答案实际上是矛盾的，即使它们被标记为彼此的副本。

• 为什么nuget在nuget包更新期间向库项目添加带有assemblybinding的app.config？

• 应用程序中是否需要bindingRedirect.config文件或所有程序集？

第一个问题的公认答案提到app.config文件实际上是在编译期间使用的，这意味着它们可能有效。像msdn和msbuild这样的源代码在这里被引用，作为它在编译期间使用的证明。不幸的是，我对msbuild不够精通，无法理解它是如何被使用的，以及它是否真的是一个有效的论点。

我有多个具有类似设置的应用程序-Web应用程序引用多个库项目，每个库项目都有自己的nuget包等，根据我的个人经验，在运行时不考虑库项目中的程序集绑定。

根应用程序(web/console)中指定的web或app config绑定仅起作用。我的所有库项目都设置为app.config文件的"复制到输出目录"设置为"不复制"-这样我的输出文件夹就不会与dll及其配置文件混在一起。

下面是一个链接，说明如何加载程序集，在哪里搜索程序集以及程序集的顺序。不，在本文中他们在哪里讨论单个项目配置文件。

希望有帮助。

根据这篇旧的msdn文章：

因此，只有设置了ISOLATIONAWARE_MANIFEST_RESOURCE_ID的dll实际使用独立的应用程序配置，否则将延迟到主进程配置文件。

有关isolationaware的更多信息，您可以阅读另一篇更深入的msdn文章。

ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It
should be used if the dll wants private dependencies other than the
process default. For example, if an dll depends on comctl32.dll
version 6.0.0.0. It should have a resource of type RT_MANIFEST, ID
ISOLATIONAWARE_MANIFEST_RESOURCE_ID to depend on comctl32.dll version
6.0.0.0, so that even if the process executable wants comctl32.dll version 5.1, the dll itself will still use the right version of
comctl32.dll.

不，只有可执行文件的app.config才有效。例如，如果您有一个控制台应用程序托管一个WCF服务，并且在您的WCF服务中使用，例如，ConfigurationManager.AppSettings，那么appsettings将来自控制台主机app.config文件。如果您启动另一个控制台应用程序(consoleclient)尝试连接到consolehost，那么在可以说consoleclient"正在执行"的部分(例如在其主方法中)，它将使用consoleclient的app.config，但一旦开始使用wcf服务，wcf服务将委托使用consolehost的edoc。X1×1。(注意，最后一点与WCF背后的细节更相关。)

令人惊讶的是，msdn提供了这个伟大的来源：https://social.msdn.microsoft.com/forums/vstudio/en-us/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings？referer=http://social.msdn.microsoft.com/forums/vstudio/en-us/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings？referer=http://social.msdn.microsoft.com/forums/vstudio/en-us/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings？论坛

通常只有一个配置文件，即可执行(.exe.config，web.config)的配置文件。

任何程序集重定向都必须放在可执行文件的配置文件中。

需要使用configurationManager类手动加载DLL的配置文件。另请参见与库(dll)的"app.config"等效的问题。