这是对依赖关系的描述:
有类似的问题&解决方案,但他们通过配置文件在运行时使用程序集绑定解决它,但我不认为这与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,但我想知道在提交/重构之前是否有更好的方法(如其他问题中的运行时程序集绑定).谢谢!
正如我在评论中所说,选项1应该随时可用,因为“v1”实际上是“预测试版”.如果第三方供应商在使用非beta版本发布版本时出现延迟,则选项2是您的下一个选项.只需确保为MyWriteableBitmapExtensions的构建使用全新的标识:特别使用不同的AssemblyName,FileName,强名称签名和用于标识的任何GUID,包括COM.
如果您不需要新功能或者v2与v1向后兼容,则程序集绑定仍然是首选选项 – 我还没有确认它是否可用于Silverlight,但如果它不是我会感到惊讶虽然我现在同意真正的程序集绑定可能在Silverlight中不可用,因为Silverlight中缺少整个System.Configuration命名空间(System.Configuration.Assemblies中的两个枚举除外).
然而,另一个选择是调整最新的源代码,以便它确实产生向后兼容v1的东西,如果你不得不打破v2功能 – 以这种方式仍然可以使用v2功能,只需使用重新编译,现在使用原始标识(AssemblyName,FileName,强名称签名等).然后,您应该能够再次为两个方案使用一个程序集.