5

在我的项目中，我的依赖层次结构存在问题。我在我的代码中使用了一个库 ( WriteableBitmapExtensions )，并且我还有另一个也使用 WriteableBitmapExtensions 的第 3 方库。只有另一个库与特定的旧版本紧密相关，我的代码需要其最新版本中的功能。

这是对依赖项的描述：依赖树

有类似的问题和解决方案，但他们通过配置文件在运行时通过程序集绑定解决它，但我认为这与 Silverlight 应用程序不兼容。

在同一解决方案中引用 2 个不同版本的 log4net

在同一文件夹中使用同一程序集的不同版本

3rd 方库是指不同版本的 log4net.dll

如何处理多个版本的依赖关系？

那么有没有办法在 Silverlight 上下文中解决这些不同版本的程序集依赖项？如果没有，我想我的选择是：

1) 很可能我可以说服 3rd 方库的供应商更新以使用最新版本的 WriteableBitmapExtensions，但我不希望依赖他们保持最新。特别是因为 WriteableBitmapExtensions 项目仍在更新中，我们经常利用它们的新功能。

2) 由于 WriteableBitmapExtensions 是开源的，我想我可以将它的源代码重新编译为一个新的程序集“MyWriteableBitmapExtensions”并在我的源代码中使用它。但是如果两个 3rd 方库引用不同版本的 WriteableBitmapExtensions，我会再次遇到这个问题。

我怀疑我会选择选项 2，但我想知道在提交/重构之前是否有更好的方法（如其他问题中的运行时程序集绑定）。谢谢！

4

1 回答 1

1

正如我在评论中所说，选项 1 应该很容易获得，因为“v1”实际上是一个“pre beta”版本。

如果第 3 方供应商延迟发布使用非 beta 版本的构建，您的选项 2 是您的下一个选项。只需确保为您的构建使用全新的身份MyWriteableBitmapExtensions：特别是使用不同的 AssemblyName、FileName、强名称签名和任何用于身份的 GUID，包括用于 COM。

如果您不需要新功能，或者如果 v2 向后兼容 v1，则程序集绑定仍然是更可取的选择——我还没有确认这是否适用于 Silverlight，但如果它不是，我会感到惊讶'虽然我现在同意真正的程序集绑定在 Silverlight 中可能不可用，因为 Silverlight 中缺少整个 System.Configuration 命名空间（除了 中的两个枚举System.Configuration.Assemblies）。

不过，另一种选择是调整最新的源代码，使其确实产生与 v1 向后兼容的东西，如果必须的话，可能会破坏 v2 功能——这样仍然可以使用 v2 功能，只需重新编译，现在使用原始标识（AssemblyName、FileName、Strong Name Signature 等）。然后，您应该能够再次将一个程序集用于这两种情况。

于 2012-04-01T07:40:17.370 回答