logo标签列表

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

.netvisual-studiomigrationenterprise-library
6
我们正在将一个包含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

5个回答
6
我们将一个相当大的解决方案（20个以上的项目）从2005升级到了2008，但这实际上是微不足道的。只是基本的项目升级而已。由于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的转换要痛苦得多...
4

我使用向导将几个项目从Visual Studio 2005升级到了2008，都很顺利（除了那只C++野兽。但是你说的是.NET）。请记住，您不需要升级.NET版本。Visual Studio 2008支持.NET 2.0、3.0和3.5。然而，3.5向后兼容，因为它与同一CLR一起运行，更多地是一些额外的库。而“旧”的库保持不变。

我不知道Entlib。

为什么不试着运行您的单元测试呢？ :)

单元测试，如果我有的话，我会写的。 :) - Wiren
1
哎呀 - 现在你知道为什么需要它们了 ;) - OregonGhost
哦，是的！这不是唯一的原因... :) - Wiren
1
1

当我从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)。
1
  • 让Visual Studio向导为我们转换解决方案有没有任何不允许的理由？

没有。

  • 3.5版本是否与2.0版本完全向后兼容？

不是。3.5版本中有一些新功能无法原生地向后移植。而且（如果我没记错的话）从2.0到3.5还有一些弃用的内容。

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

我认为不是。要求列出了3.5版本。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接