在app.config中为类库做绑定重定向会做什么吗?

我经常使用的VS解决方案包括一个可执行项目 (控制台应用程序,Web应用程序)和许多可执行文件引用的类库项目

在使用NuGet并安装软件包时,通常会为每个项目创建一个app.config文件,通常只包含合并重定向列表以合并引用程序集的版本。 有时候会有一些第三方库特定的内容(比如Entity Framework配置部分),但是现在让我们把它放在一边。

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

启动主可执行文件时,类库程序集的配置文件是否有效? 或者只是可执行文件的app.config文件在这种情况下有效? 如果在某些类库项目上设置了一些绑定重定向,并在主可执行项目上设置了一些不同的绑定重定向 – 这些如何组合,哪些优先?

我试图在线研究这个,从我读过的内容来看,它看起来像非可执行程序集的app.config文件是无用的(关于绑定重定向)。 有人可以确认这一点或详细说明该主题吗?

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


我在这个主题上找到了这些现有的Stack Overflow问题,但是他们接受的答案实际上是矛盾的,即使它们被标记为彼此重复

  • 为什么NuGet在NuGet包更新期间将app.config与assemblyBinding一起添加到LIBRARY项目?

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

第一个问题的接受答案提到app.config文件实际上是在编译时使用的,这意味着它们可能有效。 像MSDN和MSBuild源代码这样的来源被引用作为它在编译期间使用的certificate。 不幸的是,我对MSBuild的熟练程度不足以理解它是如何被使用的,以及它是否真的是一个有效的参数。

任何人都可以描述一个示例场景来certificate带有绑定重定向的类库的app.config可以做什么吗?

根据这篇旧的msdn文章 :

应用程序配置文件是用于控制程序集绑定的XML文件。 它可以将应用程序从一个版本的并排程序集重定向到同一程序集的另一个版本。 这称为每个应用程序配置。 应用程序配置文件仅适用于特定的应用程序清单和从属程序集。 使用嵌入式[ ISOLATIONAWARE_MANIFEST_RESOURCE_ID ]清单编译的独立组件需要单独的应用程序配置文件。 使用CreateActCtx管理的清单需要单独的应用程序配置文件。

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

有关ISOLATIONAWARE的更多信息,您可以阅读更深入的其他MSDN文章 。

ISOLATIONAWARE_MANIFEST_RESOURCE_ID主要用于DLL。 如果dll需要除进程默认值之外的私有依赖项,则应该使用它。 例如,如果dll依赖于comctl32.dll版本6.0.0.0。 它应该具有类型为RT_MANIFEST,ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID的资源以依赖于comctl32.dll版本6.0.0.0,因此即使进程可执行文件需要comctl32.dll版本5.1,dll本身仍将使用正确版本的comctl32.dll。

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

在根应用程序(Web /控制台)中指定web或app config的绑定是唯一重要的。 我的所有库项目都设置为“复制到输出目录”设置为“不要复制”app.config文件 – 这样我的输出文件夹不会与dll及其配置文件混乱。

这是一个链接 ,说明如何加载程序集以及搜索的位置和顺序。 没有在文章中他们谈论个别项目配置文件。

希望有所帮助。

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

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

需要使用ConfigurationManager类手动加载dll的配置文件。 另请参阅此问题等效于库的“app.config”(DLL)

不,只有可执行文件的app.config才会生效。 例如,如果您有一个托管WCF服务的控制台应用程序,并且在您的WCF服务中使用了例如ConfigurationManager.AppSettings ,则AppSettings将来自控制台主机app.config文件。 如果您启动另一个控制台应用程序(ConsoleClient)以尝试连接到ConsoleHost,那么在ConsoleClient可以说是“正在执行”的部分(例如在其主方法中),它将使用ConsoleClient的app.config ,但是一旦开始使用WCF服务,WCF服务将委托使用ConsoleHost的app.config 。 (请注意,最后一点与WCF背后的细节更相关。)

令人惊讶的是,msdn提供了这个伟大的来源: https : //social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-应用程序设置引荐= HTTP://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-设置引荐= HTTP://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?论坛= WCF