NuGet 包管理器将程序集绑定重定向添加到库项目的原因是,有些项目类型的输出类型是库,但有一些特殊机制可以确保库的应用程序或 Web 配置文件将在运行时应用。这与您可能熟悉的更典型的库用法相反,其中根本不使用库的配置文件。
例如,Azure SDK 1.8+ 中的 Azure Web 和 Worker 角色项目将生成库,但是当它们被 IIS 包装在 exe 中时,库的配置文件将被设置为默认那个exe。这样,您无需显式发布与包装可执行文件which is how it used to be done 同名的特殊配置文件即可获得所有应用程序配置。现在构建过程输出重命名的配置文件(例如 app.config -> myWebRoleLibrary.dll.config),一切正常。
XUnit also does something similar;加载测试程序集的 app.config 而不是测试运行进程的应用配置。
值得一提的是,你也可以manually load a config file in any project,图书馆与否。您必须确保配置文件最终位于正确的位置,但这是可能的。但是,这不太适用于绑定重定向,因为这些重定向通常仅由 CLR 中的程序集加载器使用。我想你可以勾搭 AssemblyLoad,但现在我们正在努力重新发明轮子。
那么,“在我的图书馆项目中是否有必要”的答案?是也许。如果您的库项目不是 Web 或辅助角色或测试项目,并且它没有手动加载配置文件,那么 app.config 可能是良性的,但没有必要。
至于禁用它,您只能在 Visual Studio 级别执行此操作。您可以在 VS2019 中找到该选项:工具 -> 选项... -> NuGet 包管理器 -> 常规 -> 跳过应用绑定重定向。
什么使用我的配置文件?
编译器 (csc.exe)
编译器使用正在构建的程序集的配置文件有一个原因:to find and use supportPortability elements。
上面的链接列出了您需要该编译器选项的罕见场景,但绝大多数用户不需要。可以这么说,如果您不知道自己是否在使用该功能,那您就没有。
它不解析配置文件的任何其他元素,包括程序集绑定重定向,这是 NuGet 添加的元素。
构建引擎 (msbuild)
MSBuild 在其几个步骤中使用应用配置,但重要的是不 来查找主要依赖项,它将以/reference: 选项的形式传递给 csc.exe。
为了查找主要引用,MSBuild(特别是 ResolveAssemblyReference 任务)将搜索the common targets file 中枚举的路径集合。如果它在您的 csproj 中找不到显式依赖项,它将发出警告,并且可能会在编译需要依赖项时进一步发出错误。
之后它将搜索传递依赖。它不会将这些文件传递给编译器,而是使用它们生成一个文件列表,这些文件需要在后续构建步骤中考虑,例如生成许可证文件、信任信息和建议的绑定重定向。此步骤确实考虑项目的配置文件,并专门使用其绑定重定向来通知传递依赖项列表。请务必注意,构建 exe 将在构建过程中不考虑其库的 app.config 文件,并且库的 app.config 不会改变库的 dll 的生成方式。
运行时 (CLR)
CLR 使用config files 到change the way it locates assemblies。
IIS
IIS 将读取您的 web.config 文件的元素以更改您的网络应用程序的行为方式。例如,caching characteristics。
应用程序
应用程序可以使用ConfigurationManager从配置文件中手动检索配置数据。