将.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的转换更加痛苦......

Answer 2

我使用向导将几个项目从Visual Studio 2005升级到2008，并且它们都无痛（好吧......除了那个C ++的野兽。但是你还在谈论.NET）。

请记住，您不需要升级.NET版本。 Visual Studio 2008支持.NET 2.0,3.0和3.5。但是，3.5无论如何都是向后兼容的，因为它位于同一个CLR上，或多或少只是一些额外的库。而“旧”图书馆保持不变。

我不知道Entlib。

为什么不尝试运行单元测试？ ：）

Answer 3

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

没有

• 3.5完全向后兼容2.0？

没有。 3.5中有一些新功能不会本地向后移植。而且（IIRC）有一些贬值从2.0到3.5。

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

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

进行备份，运行向导，看看会发生什么。这样一个庞大的项目可能需要一段时间，但你将处于一个可以判断它是否会按预期构建/运行的位置。

Answer 4

当我从EntLib 2.0升级到4.0时，如果您使用缓存应用程序块，我会发现以下破坏源代码更改：

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

另外，如果您正在为异常处理块编写自己的异常格式化程序类：

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

Answer 5

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

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

- 格里戈里“

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＆amp; p，我会更新。

阿德

Answer 6

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

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