我们正在将一个包含 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
superwiren
问问题
8105 次
5 回答
6
我们从 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 的转换要痛苦得多……
于 2008-10-02T15:44:12.920 回答
4
我使用向导将几个项目从 Visual Studio 2005 升级到 2008，并且它们都变得轻松（嗯......除了那个 C++ 野兽。但无论如何你都在谈论 .NET）。
请记住，您不需要升级 .NET 版本。Visual Studio 2008 支持 .NET 2.0、3.0 和 3.5。但是，无论如何，3.5 都是向后兼容的，因为它位于同一个 CLR 上，并且或多或少只是一些额外的库。“旧”库保持不变。
我不知道Entlib。
你为什么不试着运行你的单元测试呢？:)
于 2008-10-02T08:42:05.510 回答
1
- 是否有任何理由不让 Visual Studio 向导为我们转换解决方案？
不。
- 3.5 是否完全向后兼容 2.0？
不，3.5 中的新功能不会原生向后移植。并且（IIRC）从 2.0 到 3.5 有一些弃用。
- Entlib 4.0 是否完全向后兼容 2.0？
我不这么认为。3.5 被列为要求。
进行备份，运行向导，看看会发生什么。这样一个庞大的项目可能需要一段时间，但您将处于可以判断它是否会按预期构建/运行的位置。
于 2008-10-02T08:44:12.323 回答
1
当我从 EntLib 2.0 升级到 4.0 时，如果您使用缓存应用程序块，我观察到以下破坏性源代码更改：
- 在 2.0 中，您可以使用
CacheManager cache = CacheFactory.GetCacheManager(). - 在 4.0 中，您必须替换
CacheManager为，ICacheManager否则将无法编译。
此外，如果您正在为异常处理块编写自己的异常格式化程序类：
- 在 2.0 中，您必须定义一个带有签名的构造函数
(TextWriter, Exception)。 - 在 4.0 中，这已过时，您必须使用签名定义第二个构造函数
(TextWriter, Exception, Guid)。
于 2009-06-26T11:42:24.287 回答
1
从 EntLib 3.1 迁移到 4.0 时不应该有任何重大更改：
“公共 API 没有重大变化。这是 EL4 的设计目标之一。请记住 EL4 需要 .NET3.5。
——格里高利”
（Grigori 是 EntLib 的项目经理）
不过，我不确定 2.0 到 3.1。如果我明天能找到合适的人@p&p，我会更新这个。
阿德
于 2009-07-09T04:07:20.463 回答