.Net 2.0/3.5 和 4.0 之间的向后兼容性
我有一个应用程序，已从 3.5 升级到 4.0。但并非我所有的第 3 方程序集都是基于 .net 4.0 构建的。我怎么仍然能够毫无问题地引用这些程序集？例如，如果另一个程序集引用 system.dll 2.0，而我的升级项目引用 system.dll 4.0，.net 如何处理这种情况？
显然，这在 2.0 和 3.5 之间升级不是问题，因为它们使用相同的 BCL 和 CLR 版本，但 4.0 使用完全不同的 BCL 和 CLR，对吧？
这是一个例子。我有一个使用 v3.5 中的 WF (Windows Workflow) 构建的应用程序。我已将应用程序升级到 v4.0，但我不需要在新版本的工作流程中实现所有重大更改。它仍然使用旧的3.5版本的WF。
I have an app that I've upgraded from 3.5 to 4.0. But not all my 3rd party assemblies are built on .net 4.0. How is it that I'm still able to reference those assemblies without any problems? For instance, if another assembly references system.dll 2.0, and my upgraded project references system.dll 4.0 how does .net handle this?
Obviosly this wasn't a problem upgrading between 2.0 and 3.5 because they use the same BCL and CLR versions, but 4.0 uses a completely different BCL and CLR right?
Here's an example. I have an app built using WF (Windows Workflow) in v3.5. I've upgraded the app to v4.0, but I wasn't required to implement all the breaking changes in the new version of workflow. It still using the old 3.5 version of WF.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
BCL 和 CLR 有不同但并非完全不同。基本上他们努力不破坏向后兼容性。
BCL and CLR are different but not completely different. Basically they worked hard to not break backwards compatibility.
您还可以强制您的第 3 方程序集在 3.5 下运行，如所述 在这篇文章中。
You could also force your 3rd party assemblies to run under 3.5, as described in this post.
.NET 4.0 可以引用 .NET 2.0 程序集，但反之则不然。
.NET 4.0 程序集支持 2.0 拥有的所有内容，但添加了可选参数、动态类型等内容...
因此，由于 2.0 没有 4.0 没有的任何内容，因此 4.0 可以轻松支持 2.0。
.NET 4.0 can reference .NET 2.0 assemblies, but the reverse is not true.
.NET 4.0 assemblies support everything that 2.0 had, but adds in things like optional parameters, dynamic types, and etc...
So, since 2.0 doesn't have anything that 4.0 doesn't, 4.0 can easily support 2.0.