如果仅存在.NET 2.0 RTM，运行时如何解决对.NET 2.0 SP1程序集的调用

问题描述

| 我们在装有.NET 2.0 SP1的计算机上针对.NET 2.0构建了应用程序。该应用程序引用了.NET SP1中包含的一些标准.NET程序集（即“ 0”）。 如果我们在带有.net 2.0 RTM的计算机上运行此应用程序，则该应用程序运行良好，甚至使用了“ 0”汇编。但是，当它尝试使用2.0 RTM中不存在但2.0 SP1中存在的方法时，应用程序将抛出MethodNotFoundException。 我的问题是：运行时如何完全解析System.Xml.dll？ 装配体版本的修订号不同（但主要，次要和内部零件相同）。这意味着2.0 RTM和2.0 SP1程序集在程序集绑定过程方面有所不同。运行时应尝试找到System.Xml.dll

2.0.50727.1378

，但只能找到

2.0.50727.42

。然后，程序集绑定过程将失败，因为Machine.config中没有任何发布者策略或重定向。但是绑定工作正常。怎么可能？ 上述问题之后的另一个问题。 我们不能强迫所有客户端在其计算机上安装.NET 2.0 SP1。如果我们从.NET 2.0 SP1发行System.Xml.dll，我们如何强制我们的应用程序使用我们的应用程序随附的System.Xml.dll？ 更新1：看起来System.Xml.dll版本是2.0.0.0，而不是2.0.50727.x。这说明了运行时成功解决它的原因。但是第二个问题仍然适用：我们可以将SP1中的System.Xml.dll与我们的应用程序一起发布，并强制我们的应用程序使用它吗？     

解决方法

如果没有可接受的答案，我会发表自己的答案。希望它能帮助到别人。 第一个问题是运行时如何从Service Pack解析程序集。 我已经进行了更多调查，并阅读了一些文章。我误以为是

AssemblyFileVersion

而不是

AssemblyVersion

。对于在

.NET 2.0 SP

中的组件，

AssemblyFileVersion

是

2.0.50727.1378

，对于在assemblies9ѭ中的组件，则是

2.0.50727.42

。是的，它们是不同的，但是是

AssemblyFileVersion

，而不是

AssemblyVersion

。并且程序集绑定过程仅使用“ 5”。但是ѭ5和ѭ17分别是ѭ15和ѭ15。因此，

RTM

和

SPx

程序集在程序集绑定过程方面是相同的。 我还是很感兴趣，为什么MS并未附带增加了“ 5”的Service Pack程序集？他们可以将带有相应发布者策略的“ 21”程序集交付，以将程序集绑定从“ 18”重定向到“ 23”。并且，如果客户希望使用

RTM

版本的程序集，则可以忽略特定程序集的发布者策略。实际上，我认为MS拒绝这样做，因为如果客户端开始忽略某些程序集上的发布者策略而不忽略其他程序集上的发布者策略，那将是一团糟。超过25个程序集不能相互依赖，整个26个程序集将变得不一致。 第二个问题是关于是否可能随我们的产品一起运送27个装配件并将装订绑定从18个装配件重定向到21个装配件的可能性。 简短的回答是“不，不可能”。但是有两种可能的解决方案，但是它们相当la脚，只能在严格的情况下使用，并且通常根本不适用。 第一个解决方案是取消CLR组装，然后使用我们的公钥再次构建它，或者我们完全可以省略强签名。现在我们将能够引用此GAC的

RTM

组件，而不是

SP\'s

组件。 第二种解决方案是使用“ 33”工具用SP \的组件替换GAC中的“ 32”组件。必须使用

/f

（强制）选项。 这两种解决方案都非常la脚。请不要使用它们。通常，由于程序集之间存在某些依赖性，因此无法使用它们。 结论 在我们的产品中，我们将产品降级了，因此可以在ѭ9上工作。但是，即使是

.NET 3.x

（

linq-to-objects

，

Action

，

Func

），我们仍然使用某些功能。我们只是随我们的产品一起提供了一些3.x组件，例如

System.Core.dll

。大多数情况下，这种方法没有问题。但是由于一些无法解决的问题，我们也不得不拒绝使用“ 41”。     ,.NET版本仅适用于强名称程序集。 使用SP1编译程序时，您不能（也不应该）期望程序可以在RTM版本上正确运行。它可能正确运行，但也可能以神秘方式失败。