在我的项目中,我的依赖层次结构存在问题。我在我的代码中使用了一个库(WriteableBitmapExtensions),我还有另一个第三方库,它也使用了WriteableBitmapExtensions。只有其他库与特定的旧版本密切相关,我的代码需要最新版本的功能。
以下是依赖关系的描述:
有类似的问题&解决方案,但他们通过配置文件在运行时使用程序集绑定解决它,但我不认为这与Silverlight应用程序兼容。
Referencing 2 different versions of log4net in the same solution
Using different versions of the same assembly in the same folder
3rd party libraries refer to different versions of log4net.dll
How to deal with multiple versions of dependencies?
那么有没有办法在Silverlight上下文中解析这些不同版本的程序集依赖项?如果没有,我认为我的选择是:
1)我很可能会说服第三方库的供应商更新以使用最新版本的WriteableBitmapExtensions,但我更愿意不依赖它们使其保持最新状态。特别是因为WriteableBitmapExtensions项目仍在更新中,我们经常利用它们的新功能。
2)由于WriteableBitmapExtensions是开源的,我想我可以将其源代码重新编译为新的程序集“MyWriteableBitmapExtensions”并在我的源代码中使用它。但是如果两个第三方库引用了不同版本的WriteableBitmapExtensions,我将再次遇到这个问题。
我怀疑我将使用选项2,但我想知道在提交/重构之前是否有更好的方法(如其他问题中的运行时程序集绑定)。谢谢!
答案 0 :(得分:1)
正如我在评论中所说,选项1应该随时可用,因为“v1”实际上是“预测试版”。
如果第三方供应商在使用非测试版发布版本时出现延迟,则您的选项2是您的下一个选项。只需确保为MyWriteableBitmapExtensions
的构建使用全新的标识:特别使用不同的AssemblyName,FileName,强名称签名和用于标识的任何GUID,包括COM。
如果您不需要新功能或者v2与v1向后兼容,则程序集绑定仍然是首选选项 - 我还没有确认Silverlight是否可以使用它,但我'如果它不是,我会感到惊讶,虽然我现在同意真正的程序集绑定可能在Silverlight中不可用,因为Silverlight中缺少整个System.Configuration命名空间(System.Configuration.Assemblies
中的两个枚举除外)。
然而,另一种选择是调整最新的源代码,以便 生成与v1向后兼容的东西,如果必须,可能会打破v2功能 - 以这种方式v2功能仍然可以使用,只需重新编译,现在带原始标识(AssemblyName,FileName,强名称签名等)。然后,您应该能够再次为这两个场景使用一个程序集。