.net - 将.net 2.0解决方案转换为.net 3.5的陷阱

Question

我们将一个包含20多个项目的解决方案从.net 2.0迁移到3.5，同时将Visual Studio 2005迁移到2008。同时，我们也从MS Entlib 2.0迁移到4.0。

是否有任何理由不让
Visual Studio向导将
为我们解决方案？

是3.5完全向后兼容
2.0？

Entlib 4.0是否完全向后兼容
2.0？

编辑:当我写这篇文章的时候，我可能有点困惑，向后兼容性应该是这样。 2.0项目中是否存在无法在3.5版本中工作/编译的任何内容

:)

//W

Answer 1

从2005年到2008年，我们升级了一个相当大的解决方案(超过20个项目)，但这确实微不足道。项目基本上只是升级。由于3.0/3.5和2.0共享相同的核心框架，因此基础框架仍然相同。

如上所述，即使您正在升级，也无需更改项目的框架引用-实际上，默认情况下，它将框架保留为2.0，而不是将其更改为3.0/3.5。这意味着除非更改引用(项目属性页，应用程序表“目标框架”字段)，否则您将无法利用3.0/3.5的功能，但是这也意味着您可以放心，不会再有其他兼容性。问题(因为在更改该引用之前，添加3.0/3.5代码会出现错误)。

尽管您无需升级应用程序即可使用TFS 2008，但也不应忽视TFS 2008的新功能。

从1.1到2.0的转换要痛苦得多...