我们将一个包含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

解决方案

我使用向导将几个项目从Visual Studio 2005升级到了2008，它们都很轻松(嗯……除了那个C ++野兽。但是无论如何，我们都在谈论.NET)。

请记住，我们不需要升级.NET版本。 Visual Studio 2008支持.NET 2.0、3.0和3.5. 但是，3.5无论如何都向后兼容，因为它位于同一CLR上，或者多或者少只是一些额外的库。和"旧"库保持不变。

我不了解Entlib。

我们为什么不尝试运行单元测试？ :)

• 有什么理由不让Visual Studio向导为我们转换解决方案？

不。

• 3.5与2.0完全向后兼容吗？

不会。3.5版中有一些新功能不会原生向后移植。而且(IIRC)从2.0到3.5会有一些弃用。

• Entlib 4.0与2.0完全向后兼容吗？

我不这么认为。 3.5列为要求。

进行备份，运行向导，看看会发生什么。这样一个庞大的项目可能需要一段时间，但是我们将可以确定它是否可以按预期的方式进行构建/运行。

从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的转换要痛苦得多...

当我从EntLib 2.0升级到4.0时，如果我们使用Caching应用程序块，则会观察到以下重大源代码更改：

• 在2.0中，我们可以使用CacheManager cache = CacheFactory.GetCacheManager()获取缓存管理器。
• 在4.0中，我们必须将CacheManager替换为ICacheManager，否则它将无法编译。

另外，如果我们要为"异常处理"块编写自己的异常格式化程序类，请执行以下操作：

• 在2.0中，我们必须定义一个带有签名(TextWriter，Exception)的构造函数。
• 在4.0中，这已经过时了，我们必须使用签名(TextWriter，Exception，Guid)定义第二个构造函数。

从EntLib 3.1迁移到4.0时，不应有任何重大更改：

"公共API并没有重大变化。这是EL4的设计目标之一。请记住，EL4需要.NET3.5.

-格里哥里(Grigori)

http://blogs.msdn.com/agile/archive/2008/05/16/enterprise-library-4-0-for-visual-studio-2008-released.aspx

(Grigori是EntLib的程序经理)

我不确定2.0到3.1. 如果明天能在p＆p找到合适的人，我将进行更新。

阿德

检查此链接，了解如何从.net 2.0迁移到.net 3.5

http://codingreview.blogspot.com/2009/09/how-to-migrate-your-application-from.html