我的.NET 2.0应用程序将继续工作多长时间？

时间：2012-03-02 20:32:03

标签： .net winapi

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

  • 支持.NET Framework 1.1截止日期为09/09/2005
  • 对.NET Framework 2.0的支持已于12/01/2010结束
  • 对.NET Framework 3.0的支持已于12/07/2011结束

我拥有用.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位上运行。）

我今天写的原生程序将在18年后仍然有效（可能）。但似乎我今天写的.NET程序无法保证它将继续运行。

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

在某处，如果我使用.NET 2.0或更高版本编写托管应用程序，是否应继续在Windows 8，Windows 9，Windows 10等上运行？

.NET Framework 1.1错误的案例

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

enter image description here

这是班级：

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

所以我创建了一个小测试应用程序，看看 I 是否可以创建相同的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 Framework 4，那么我想我可以责怪应用程序的安装程序。

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

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

我只是假设这两个陈述不能同时成立。

5 个答案:

答案 0 :(得分：8)

大多数.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都包含错误修复和与安全相关的更改，这些更改可能会影响某些应用程序和组件的兼容性。

答案 1 :(得分：5)

  

如果您尝试在现代Windows 7 64位计算机上安装.NET Framework 1.1版，则会出现错误 - 它将无法正常工作。 2006年编写的程序不再可用;你也可以扔掉它。

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

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

答案 2 :(得分：1)

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

答案 3 :(得分：0)

.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

答案 4 :(得分：0)

＆＃34;在这些过渡期间破坏的应用程序是那些首先违反规则的应用程序。＆＃34;那是错的。

为什么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
}

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

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

相关问题
最新问题