这里的一些程序员一直在用 VB6 开发一个项目，他们说如果他们希望他们的应用程序在更新/未来的系统上运行，他们现在需要升级到 vb.net，因为 vb6 很快就会成为历史。
所以他们一直在处理这个巨大的应用程序，他们将不得不从头开始重建（他们尝试使用升级向导，但错误太多）
公司的所有者对于在一个项目上投入这么多时间而不得不转身从头开始重做它并不太兴奋。
这不是我的项目，我对 vb 一无所知，我是一名网络程序员。
但是这些人能做什么，这样就不会再发生这种情况，或者他们应该怎么做，这样现在就不会成为问题了？
是否有某种方法可以确保您的应用程序始终具有可扩展性并且不会过时并且需要重新编写？
谢谢！
不，实际上没有任何东西，尽管 Windows 7 仍然可以运行 DOS 程序，所以它们的程序不会无法运行。他们将遇到的最大问题是没有新的支持或新功能，以及该主题的知识社区不断缩小。
我的公司目前在 Fortran、Clipper、VB6 和 FoxPro 中运行程序，仅举几例，其中一些已经存在 20 多年，并且在所有 Windows 升级中毫发无损。通常使旧程序无法使用的原因是无法重新编译程序以修复错误。
打破程序的功能当然会有所帮助，这样如果您决定从 VB6 迁移到 VB .Net，那么挑选可重用代码会容易得多。
很好的问题。
简短的回答是否定的。因为所有代码最终都会过时。
如果您在 x86 汇编器中编写代码，那么它会持续一段时间。C 代码的保质期也很长。但问题在于，由于许多因素，技术从组装机中抽象出来的越多，其保质期就越短。
不要使用专有语言。当然库和平台可能会改变，但有趣的是语言本身已经过时了。坚持使用 C、C++ 或任何拥有大量开源用户群的东西。即使维护者停止支持它们，它们也可能会存在一段时间——这意味着 Python、Ruby、Java，可能还有C#。我的水晶球在 C 和 C++ 之外不是那么好，但有令人信服的理由让其他一个可以持续 20 到 50 年。
Visual Basic 很有趣，但是从架构的角度来看，它所提倡的代码和 UI 的混合是很糟糕的。一个好的设计应该使更改后端、GUI 工具包和操作系统变得可行（不一定超级容易）。
你有点被一种语言困住了，所以选择一种不局限于不断改变它的供应商的语言。
尝试阅读Joel 的Fire and Motion。
正如其他人所说，这不是“我的应用程序如何不被淘汰”。更多的是“当我的应用程序过时了，我怎样才能快速恢复。” 实际上，这只是其他问题的不同版本：
这就是 OO 和 SOA 试图回答的问题。构建许多小型独立应用程序，并使用标准机制将它们松散地耦合在一起。当您出于任何原因需要升级时，请将其拔出、升级并重新插入。
我不知道有任何公认的方法可以防止未维护的应用程序过时。
如果您想防止产品过时，则将其设计为可升级的。
至少在 .NET 中，您有很多很多的选项来创建可重用的组件：
单独的程序集，可以在任何 .NET 项目中使用，如果需要使用不同的技术，可以在以后扩展以支持 COM 互操作。
网页服务; 这些可以公开暴露并在几乎任何环境中使用。
接口和控制反转可用于支持可自由互换的组件，理论上这些组件可能来自甚至不是 .NET 的东西（只需构建一个 COM 包装器）；
进程间通信——如果一切都失败了，你可以直接创建一个内存映射文件或命名管道，并开始从（或注定）一个全新的应用程序中汇集数据。
事实上，其中一些可能适用于您当前的 VB 项目。通常有无数不同的方法可以延长现有产品的使用寿命，同时逐渐将核心功能转变为新技术。
我不是 SOA 的铁杆，但这正是 SOA 试图解决的问题。我做了很多服务——事实上，这里几乎所有重要的东西都会在某个时候通过某种 Web 服务——而且我知道我可以随时完全删除一项服务并将其替换为不同的平台。它所要做的就是吐出 SOAP 或 JSON，我的 .NET 客户端仍然可以使用它。或者，如果我需要替换客户端，我可以直接连接到服务中已经存在的富域模型。
事实上，我已经这样做了——该架构曾经完全构建在 Delphi 7 平台之上。现在一切都在 .NET 3.5 上，从一个系统到另一个系统从来没有真正的硬切换。我们开始构建普通的 SOAP 服务，然后将很多应用程序内的业务逻辑转移到服务中，最终，当应用程序只不过是一个外壳时，我们用几个 .NET 客户端（有几个单独的应用程序），然后开始添加只能在较新平台上支持的各种安全功能和优化。等等等等。
因此，如果您提前计划，它绝对可以完成。当然，这里有很多人会建议不要提前计划，引用 YAGNI ……对于某些项目，也许这是真的。这完全取决于项目的成本/任务关键程度。如果产品需要使用 50 年，那么您可能需要考虑投资一些可靠的架构和设计，以便您轻松添加和删除子组件。
考虑到围绕编程的技术的快速发展，过时是我们应用程序正常生命周期的一部分。
我真的不知道桌面/服务器应用程序，但是，在 web 开发中，我们说 5 年很长，例如 ^^
当然，可以更新、打补丁、更正、修复等等……但这样做通常会降低代码质量和应用程序本身的质量——这意味着随着时间的推移，维护成本会越来越高; 最后，重写所有内容可能意味着在维护上花费更少的钱。
最好的方法是使用跨平台的开发工具和库。这样，Microsoft 就不能弃用您所依赖的东西（因为它们无法控制它们）。如果您依赖某个供应商提供的任何特定内容，那么他们很可能会在某个时候把您搞砸。
他们应该问自己为什么他们认为用 VB6 编写这个项目是个好主意！难道他们不知道它已经不受支持和过时了吗？如果您开始使用过时的技术，您能期待什么？
他们还应该考虑改进 VB6 代码的结构并使其更加面向对象。这将使向 .NET 的过渡更容易。除此之外，他们可以尝试将功能分离到通过 COM 访问的外部类中。然后可以从 VB.NET 访问这些相同的类。此外，这些较小的部分可能更容易迁移。
我一定在二月份错过了这个问题，对不起。据我所知，没有人解决您同事的结论，即他们将不得不从头开始重建 [他们的 VB6 应用程序]才能迁移到 .Net。
这是错误的：他们不必重写，有替代方法，它们通常比完全重写更容易和更便宜。
这是来自Microsoft UK的官方建议：
对 .NET 进行完全重写要比转换成本高得多，而且很难做好[比转换]……我们只在少数情况下推荐这种方法。
来自一位咨询重写的微软人的博客文章：
我在 .NET 早期工作过的许多公司首先考虑重写，部分原因是在迁移到 .NET 的同时，他们强烈希望改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了。[这是你的同事与他们的老板发生严重麻烦的地方——人们在这一点上被解雇]
告诉您的同事通过截屏视频查看 Microsoft UK 的建议，该视频解释了 VB6 -> VB.Net 迁移的 5 个基本选项。他们应该与老板一起选择前进的道路。它可能是重写，但他们应该睁大眼睛进入它。
他们可能不应该在 VB6 中编写任何新的东西......
不要专注于不能过时的代码。您很少在适用的堆栈中工作。相反，让您的代码清晰简洁，以便您可以在时机成熟时迁移它。相反，专注于不让自己过时。努力保持最新状态并了解堆栈中正在发生的事情，并尝试了解正在发生的事情，即使您无法花时间完全投入其中。
考虑到仿真和虚拟机，我感觉“遗留”代码的寿命实际上比以前想象的还要长。您应该关注的更多是工具，而不是操作系统。
它取决于（也许）将代码与设计分离，尤其是在 Web 应用程序中，这些应用程序通常高度受时尚变幻莫测的影响。但是代码库是否可以在当前技术上运行，即操作系统仍然会运行它，那么就没有理由“升级”。
确保您的代码永远存在的真正方法是编写一个应用程序，该应用程序在使用中变得如此不可或缺，但重写所有内容（包括不过时的操作系统和硬件）以确保其继续运行。我相信这方面的一个例子是美国社会保障/政府领域的一些核心系统仍在运行 1960 年代初期的 COBOL 编写并在旧的 IBM 大型机上运行。
开源它，或者至少建立在开源平台上。
我不知道 1970 年代的任何专有系统，我们正在以与其旧用法兼容的方式使用，但我知道许多开源系统。
这不是一个完美的机制——所有语言都在这些时间尺度上发生了细微的变化，然后你必须升级你的代码以获得最新的东西。但是我知道很多服务器运行的代码已经存在了几十年，没有任何变化。
更好的是，开源它，或者尽可能多地开源。比什么都不做更好的是在其他人为您更新它时什么也不做。社区开始需要努力，但一旦开始，他们就很难停止！
任何非开源程序的效用在有限时间后都会下降到零。不能保证开源会导致它保持非零，但至少有机会。
写入当前正在认真使用的标准（ANSI 或 ISO，我会避免使用 ECMA）定义。避免任何依赖于一家公司的事情，或者唯一的完整实施来自一家公司。不要使用供应商语言扩展。小心避免对语言的假设，例如数据类型大小：如果您使用int来保存内存大小而不是size_t，则可能会使在 64 位系统上运行变得更加困难。
请记住，Microsoft 在保持向后兼容性方面非常出色，他们为您破解了 VB6。任何其他公司都可能会更糟。
在任何重要的应用程序中，都会有依赖于平台的部分。隔离它们，以限制平台发生变化时必须重写的内容。
显然，这是有代价的。例如，我建议 Windows 应用程序在 Visual C++ 中完成，通过抽象层使用 MFC，因为 C#、.NET、VB.NET 和 F# 不符合我的标准。但是，如果这是您的目标，这就是创建持久程序的方法。