将 .net 2.0 解决方案转换为 .net 3.5 的陷阱
https://stackoverflow.com/questions/161368
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们正在将包含 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
解决方案
从 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 的转换要痛苦得多......
其他提示
我使用向导将几个项目从 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 被列为要求。
进行备份，运行向导，看看会发生什么。对于这样一个庞大的项目可能需要一段时间，但您将能够判断它是否会按预期构建/运行。
当我从 EntLib 2.0 升级到 4.0 时，如果您使用缓存应用程序块，我会观察到以下破坏性源代码更改：
- 在 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 是 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
