【发布时间】：2018-10-21 06:08:18
【问题描述】：
我有一个带有插件架构的 ASP.NET 项目。我的引用链中有一个强命名的 dll 依赖项，应用程序和插件都依赖它。当应用程序使用新的依赖 dll 更新时，我真的希望能够使用一些针对旧版本的依赖 dll 编译的旧插件。
目前，当我调用 Assembly.GetTypes() 时，我得到一个 ReflectionTypeLoadException，其中包含 5 个 FileLoadException 类型的 LoaderExceptions，它们都在抱怨同一个 dll。 （系统中的dll多了很多，强名和弱名都有，可能是依赖链导致LoaderExceptions重复？）
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions
我尝试添加到我的 web.config 文件中。
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="Common.Production"
publicKeyToken="0e80e12b03b04a71"
culture="en-us" />
<bindingRedirect oldVersion="2.0.0.1459" newVersion="2.0.0.1463" />
</dependentAssembly>
但我仍然遇到同样的错误。我尝试在依赖树中添加我知道的所有强类型 dll，错误消息或 LoaderExceptions 的数量没有变化。
IL DASM 显示我的密钥和版本正确，尽管它使用的语法略有不同：
.assembly extern Common.Production
{
.publickeytoken = (0E 80 E1 2B 03 B0 4A 71 ) // ...+..Jq
.ver 2:0:0:1459
}
我的日志包含以下加载器信息：
LOG: Using application configuration file: ...\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Common.Production, Version=2.0.0.1459, Culture=neutral, PublicKeyToken=0e80e12b03b04a71
...
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
is it possible to ignore assembly manifest mismatch? 如果签名密钥已更改，则 bindingRedirect 将不起作用。另一个针对较新版本构建的组件（在 IL DASM 中检查使用相同的公钥令牌。它没有改变：
.assembly extern Common.Production
{
.publickeytoken = (0E 80 E1 2B 03 B0 4A 71 ) // ...+..Jq
.ver 2:0:0:1463
}
https://msdn.microsoft.com/en-us/library/ms973843.aspx
- 我们不想在 GAC 中存储 dll，我们希望插件使用最新版本的库。
- 版本策略，已尝试如上实施。尝试将应用程序特定策略的范围扩大到
oldVersion="0.0.0.0-2.0.0.1459"无发布者策略。机器策略未提及此程序集。 - .NET Framework 配置工具？我在我的机器上找不到这个。
https://stackoverflow.com/a/7889272/2091951 可能是？听起来有风险？程序集中不应该有我不使用的类型，这似乎以后会咬我。
http://code.fitness/post/2016/12/assembly-binding-redirect.html
- 尝试更改为
culture="neutral"，尝试删除culture - 问题可能在依赖链的下游。我已经在 app.config 中包含了我所知道的所有四个可能的罪魁祸首。如何找到罪魁祸首？
除了重新编译依赖项并删除签名并重新发布所有重新编译而没有强命名引用的插件之外，是否有其他解决方案可供我使用？该部门中没有人（包括一名前成员）有充分的理由解释为什么这个库被强烈命名，但我们确实有理由不想重新编译插件。
Could not load file or assembly or one of its dependencies
- 我没有从 FusLogvw 获得任何结果，是的，我确实启用了注册表项并重新启动。我在 log4net 日志中获得的信息相当完整，它确实显示了配置文件的处理过程和失败的原因，但我不明白为什么 web.config 项目没有被应用。
参考链接：
【问题讨论】：
-
办公室内的建议是，对于未加载的程序集中的每种类型，重复错误是一次？
标签： c# exception reflection web-config gettype