我的 .NET 2.0 应用程序可以继续工作多久？

Question

每个版本的微软 .NET 框架都有a limited support lifetime，例如：

• 对 .NET Framework 1.1 的支持于 2005 年 9 月 9 日结束
• 对 .NET Framework 2.0 的支持已于 2010 年 12 月 1 日结束
• 对 .NET Framework 3.0 的支持于 2011 年 12 月 7 日结束

我拥有使用 .NET Framework 1.1 编写的 an application from 2004。如果您尝试在现代 Windows 7 64 位计算机上安装 .NET Framework 1.1 版，您将收到一个错误 - 它无法正常工作。 2006 年编写的程序不再可用；你还不如把它扔掉。

这是否意味着我今天用 .NET 3.5 编写的程序在未来的某个时间点将无法使用？

Microsoft 竭尽全力使用 Windows API 来保持向后兼容性。 18 年前编写的程序（用于 Win32 或Win32s）今天仍然可以在 Windows 上运行。 （我知道 - 我拥有一个。它最初在 Windows 3.1 上运行，现在仍然在 Windows 7 64 位上运行。）

我今天编写的 native 程序在 18 年后（很可能）仍然可以工作。但是，我今天编写的 .NET 程序似乎无法保证它会继续运行。

Microsoft 对 .NET 框架 2.0 或更高版本是否有任何兼容性承诺？我知道 .NET Framework 1/1.1 是一个丑陋的继子； .NET 框架 2.0 破坏了与 1.1 的兼容性；但是自 2.0 以来的每个框架都与 2.0 兼容。

是否有注释表明，如果我使用 .NET 2.0 或更高版本编写托管应用程序，它应该继续在 Windows 8、Windows 9、Windows 10 等系统上运行？

---

.NET Framework 1.1 错误案例

使用 Process Explorer 监视程序，我发现它正在尝试创建的 .NET 对象，但失败了：

这是类：

• clsid：{60EBA0BC-D6AF-41C2-9584-D48D3DA39999}
• 程序：Engine.Factory

所以我创建了一个小测试应用程序，看看 我 是否可以创建相同的 COM 对象：

const Guid CLSID_EngineFactory = '{60EBA0BC-D6AF-41C2-9584-D48D3DA39999}';

IUnknown unk = CoCreateIntance(CLSID_EngineFactory, null, CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER, IUnknown);

这对我来说也失败了。我在注册表中找到了注册详细信息：

HKEY_CLASSES_ROOT\Wow6432Node\CLSID
   {60EBA0BC-D6AF-41C2-9584-D48D3DA39999}
      InprocServer32
            (Default)       mscoree.dll
            Assembly        mcengr, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
            Class           Engine.Factory
            RuntimeVersion  v1.1.4322
            ThreadingModel  Both

如果程序应该在安装了 .NET 框架 4 的情况下运行，那么我想我可以责怪应用程序的安装程序。

这很可能是我问题的答案：

• 虽然不再支持 .NET Framework 1.1，
• .NET Framework 1.1 仍受支持

我只是假设这两个陈述不可能同时为真。

Answer 1

“在这些过渡期间出现问题的应用程序是那些一开始就违反规则的应用程序。”那是错的。

为什么 MS 的兼容性很难维护？ 与 Windows 7 相比，Windows 8 带来了很多变化，例如 Windows 8 中的新代码页（区域设置）处理。

示例： 在 Windows 8 上枚举 InputLanguage.InstalledInputLanguages 并从语言中获取 CultureInfo。如果您在控制面板（键盘布局）中添加了区域设置 ID 为 0x04092000（西班牙语、美国）的语言，Framework 2 将抛出异常，因为它无法处理此区域设置。 （虽然相同的 Framework 2 代码适用于 Windows XP 和 7）

foreach (InputLanguage lang in InputLanguage.InstalledInputLanguages)
{
    CultureInfo info = lang.Culture; // throws
}

Framework 4 已更新以处理此问题。因此，由于操作系统的变化，旧框架可能无法在新操作系统上运行。

因此，新的 .NET 框架会适应这些操作系统变化，而不再维护的旧 .NET 框架则不会，并且相同的应用程序不再在新的操作系统上运行。

Answer 2

.NET 3.5 SP1 和组件（包括 2.0 SP2 和 3.0 SP2）现在支持作为 Windows 的组件并遵循它的支持生命周期： http://blogs.technet.com/b/lifecycle/archive/2010/04/30/net-framework-3-5-sp1-and-later-now-supported-as-part-of-microsoft-windows.aspx

Answer 3

大多数 .NET 1.1 程序应该可以在 .NET 2 甚至 .NET 4 运行时上正常运行。该框架具有代替运行旧版本的能力。唯一的例外是应用程序使用了在框架版本之间发生更改的内容（所谓的重大更改）。

话虽如此，我不明白为什么 .NET 2 不受支持，只要 .NET 3 和 3.5，因为 3 和 3.5 是 .NET 2 的超集。

所以答案是，您的应用程序应该在未来很长一段时间内继续工作，除非您碰巧有一些依赖于重大更改的代码。

来自马口，Version Compatibility in the .NET Framework（MSDN）：

.NET Framework 4 向后兼容使用 .NET Framework 版本 1.1、2.0、3.0 和 3.5 构建的应用程序。换句话说，使用以前版本的 .NET Framework 构建的应用程序和组件可以在 .NET Framework 4 上运行。

但是，在实践中，这种兼容性可能会因 .NET Framework 中看似无关紧要的更改和编程技术的更改而被破坏。例如，.NET Framework 4 中的性能改进可能会暴露早期版本中没有出现的竞争条件。同样，使用 .NET Framework 程序集的硬编码路径、与特定版本的 .NET Framework 执行相等比较以及使用反射获取私有字段的值都不是向后兼容的做法。此外，每个版本的 .NET Framework 都包含可能影响某些应用程序和组件兼容性的错误修复和与安全相关的更改。

Answer 4

如果您尝试在现代 Windows 7 64 位计算机上安装 .NET Framework 1.1 版，您将收到一个错误 - 它无法正常工作。 2006 年编写的程序不再可用；你还不如把它扔掉。

我不相信这是真的。除非应用程序特别需要 .NET 1.1（而不是更高版本），否则我希望它在没有任何更改的情况下仍然可以工作。如果情况并非如此，那么app.config 文件可以告诉引导代码使用更新版本的框架。

在大多数情况下，我希望这没问题，除非它依赖于以向后不兼容的方式更改的东西。重大更改非常罕见 - 但它们可以像在托管代码中一样容易地发生在本机代码中。

Answer 5

我猜如果你在编译的输出中包含你使用的库 - 只要 Windows 存在并且以相同的方式工作。