3

我们在安装了 .NET 2.0 SP1 的机器上针对 .NET 2.0 构建了应用程序。System.Xml.dll该应用程序引用了一些包含在 .NET SP1（即）中的标准 .NET 程序集。

如果我们在具有 .net 2.0 RTM 的计算机上运行此应用程序，该应用程序运行良好，它甚至使用System.Xml.dll汇编。但是，当它尝试使用 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 与我们的应用程序一起发送并强制我们的应用程序使用它？

4

2 回答 2

1

如果没有可接受的答案，我会发布我自己的。希望它可以帮助某人。

第一个问题是运行时如何从服务包中解析程序集。

我进行了更多调查并阅读了一些文章。我错误地看了一下AssemblyFileVersion而不是AssemblyVersion. 对于.NET 2.0 SP AssemblyFileVersionis2.0.50727.1378中的程序集，以及来自.NET 2.0 RTMit 的程序集2.0.50727.42。是的，它们是不同的，但它是AssemblyFileVersion，不是AssemblyVersion。和程序集绑定过程AssemblyVersion只使用。But AssemblyVersionis 2.0.0.0for .NET 2.0 RTMand .NET SPxeither。因此，就程序集绑定过程而言，RTM和SPx程序集是相同的。

我仍然很感兴趣，为什么 MS 没有提供带有 incremented 的 service pack 程序集AssemblyVersion？他们可以SP's使用相应的发布者策略发送程序集，以将程序集绑定从 重定向RTM到SP. 如果客户想要使用RTM程序集的版本，他们可以忽略特定程序集的发布者策略。实际上，我认为 MS 拒绝这样做，因为如果客户端开始忽略某些程序集上的发布者策略并且不忽略其他程序集，那将是一团糟。比BCL's组件不能相互依赖，整体BCL会变得不一致。

第二个问题是关于.NET 2.0 SP1与我们的产品一起运送组件以及将组件绑定从RTM组件重定向到组件的可能性SP's。

简短的回答是“不，这是不可能的”。但是有两种可能的解决方案，但它们很蹩脚，只能在严格的情况下使用，而且通常根本不适用。

第一个解决方案是解除 CLR 程序集，然后使用我们的公钥重新构建它，或者我们可以完全省略强签名。现在我们将能够引用这个RTM程序集，而不是SP's来自 GAC 的程序集。

第二种解决方案是使用该工具RTM's将 GAC 中的程序集替换为 SP 的程序集。必须使用 (force) 选项gacutil。/f

这两种解决方案都非常蹩脚。请不要使用它们。通常，由于程序集之间的某些依赖关系，它们不能被使用。

结论

在我们的产品中，我们降级了我们的产品，以便它可以继续工作.NET 2.0 RTM。但是我们仍然使用一些功能，甚至来自.NET 3.x( linq-to-objects, Action, Func)。我们只是随我们的产品一起提供了一些 3.x 程序集，例如System.Core.dll. 大多数情况下，我们对这种方法没有任何问题。Linq-to-Xml但由于一些无法解决的问题，我们也不得不拒绝使用。

于 2011-04-12T18:42:41.020 回答
0

.NET 版本控制仅对强名称程序集强制执行。

当使用 SP1 编译程序时，您不能（也不应该）期望程序在 RTM 版本上正确运行。它可能运行正确，但也可能以神秘的方式失败。

于 2011-03-21T10:17:14.027 回答