blocks|key|2783735|text|我每次做的选择都是重写，或者买一个合适的替代品，如果我能找到的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2783736|我尝试过从VB6到VB.NET进行增量升级，但我不喜欢这种方法，因为它只留下了我不想使用的ActiveX控件。重写更干净。|2783737|我不认为有从VB5到C#的转换器。您可能可以从VB5转到VB.NET，然后转换为C#，但根据我的经验，重写比尝试升级和修改已损坏的代码要费时少。|2783738|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

The choice I've made every time is to just re-write, or purchase a suitable replacement if I could find one.

I have tried doing incremental upgrades from VB6 to VB.NET, but I don't like that approach because it leaves around ActiveX controls that I'd rather not use. Re-writing is cleaner. 

I don't think there is a converter from VB5 to C#. You might be able to go from VB5 to VB.NET and then convert to C#, but in my experience it's less time-consuming to re-write than it is to try to upgrade and fiddle around with the broken code.

blocks|key|2783754|text|没有可靠的方法来做，所以它是1或3)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2783755|我认为你的客户不想付钱。但也许你可以在可靠性，支持等方面出售它。|2783756|否则你就会陷入困境|2783757|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There is no reliable way to do 2) so it's 1) or 3). 

And I don't think your customer wants to pay for 3). But maybe you can sell it on reliability, support etc. 

Otherwise you're stuck with 1)

blocks|key|2783763|text|一种方法是在C#中策略地重写代码的部分--您可以从您可能最容易出错的区域开始，创建C#程序集来镜像功能，然后通过COM互操作将这些代码公开给VB5代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2783764|一套好的单元测试将被强烈推荐为这种方法！|2783765|我听说迈克尔·羽毛写的“有效地使用遗产代码”是理解如何最好地解决这样一个问题的最好的书。|offset|length|2783766|entityMap|0|LINK|mutability|MUTABLE|url|http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052^0|0|0|C|9|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

One approach would be to tactically rewrite sections of the code in C# - you could start with the areas you are likely to be bugfixing the most, create C# assemblies to mirror the functionality, and then expose these to the VB5 code through COM interop.

A good suite of Unit Tests would be highly recommended for this approach!

I've heard that <a href="http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052" rel="nofollow noreferrer">Working Effectively With Legacy Code</a> by Michael Feathers is the best book around for understanding how best to chop up a problem like this.

blocks|key|2424409|text|答案肯定要取决于许多因素。我最近有一个类似的项目(一个10年多的VB6+Windows应用程序，它有一个大型的意大利面代码库)，并以“混合”的方式解决了这个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2424410|在VB6中修复了错误|unordered-list-item|2424411|在.NET+4中，使用COM互操作开发了新特性。|2424412|我们开发了一些WPF对话框，并将它们设置为与旧界面一起处理新UI的样式。|2424413|这个选项只有在新功能完全独立于主应用程序时才有效，但它的优势是至少利用了新技术的生产力，并为未来的转换铺平了道路。|2424414|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|L|$]]

The answer definitely depends on a lot of factors. I recently had a similar project (a 10-year plus old VB6 Windows app with a large, spaghetti codebase), and addressed it with a "hybrid" approach:

<ul>
<li>Bugs were fixed in VB6</li>
<li>New features were developed in .NET 4, using COM interop</li>
</ul>

We developed some WPF dialogs and styled them to go with the old interface to handle new UI.

This option only works when the new features are fairly independent of the main app, but it has the advantage of at least taking advantage of the productivity of new technologies and also paving the way for future conversion.

blocks|key|2424496|text|我最近完成了一个项目，在这个项目中，我们使用VB6将许多遗留的C#应用程序转换为Artinsoft的VB升级公司。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2424497|要决定哪种方法是最好的，这是一个艰难的决定。在很多情况下，转换代码可能会非常痛苦，特别是如果围绕两个平台之间存在显著差异的特性(例如，一个索引数组，或者通过Information.Err对象而不是通过异常处理错误)存在大量的逻辑问题。|2424498|另一方面，如果您试图从头开始编写它，很可能会意外地更改一些在查看原始VB5代码时不太明显的微妙行为。像这样的事情很难找到。|2424499|一个很好的折衷方法是使用一个转换器来移植代码，然后用它作为从头开始编写代码的指南，因为希望有一些地方可以将转换后的代码直接移到新的代码库中。同时，您还可以在其他地方编写更易于维护的代码。|2424500|尽管如此，如果原始VB5编写得很好，并且(相对地)具有良好的架构，那么我建议您不要进行任何升级。您将花费更多的时间试图匹配旧应用程序的现有行为，而不是仅仅处理旧代码。|2424501|无论你决定做什么，祝你好运--你将需要它:)|2424502|entityMap|0|LINK|mutability|MUTABLE|url|http://www.artinsoft.com/pr_vbcompanion.aspx^0|14|G|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

I've recently finished working on a project where we converted a lot of legacy VB6 applications to C# using <a href="http://www.artinsoft.com/pr_vbcompanion.aspx" rel="nofollow">Artinsoft's VB Upgrade Companion</a>.

It's a tough call to decide which approach is the best. In a lot of cases, converting the code can end up being very painful, especially if there is a lot of logic based around features which are significantly different between the two platforms (e.g. one-indexed arrays, or handling errors via the Information.Err object instead of through exceptions).

On the other hand, if you try to write it from scratch, there is a good chance that you'll accidentally change some subtle behaviour that isn't immediately obvious when reviewing the original VB5 code. Things like this can be difficult to track down.

A good compromise is to use a converter to port the code over, then use this as a guide for writing things from scratch, as there will hopefully be places where you can just lift converted code across straight into the new code base. At the same time though, you get the benefit of writing more maintainable code everywhere else.

With all that said, if the original VB5 is well written and (relatively) well architected, then I would recommend against any sort of upgrade. You will spend far more time trying to match the existing behaviour of the old application than you would just working on the old code.

Good luck with whatever you decide to do - you'll need it :)

blocks|key|1227635|text|也许您应该先转换为vb.net，然后再转换为C#？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1227636|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Maybe you should first convert to vb.net, and then to C#?

blocks|key|1227766|text|如果您只需要修复一个bug，而且它是一个相当简单的bug，那么除了这个问题之外，您不会期待更多的工作--坚持使用VB5。其他任何事情都会带来更多的工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1227767|然而，如果这真的是一个“现场”产品，你希望在未来的许多工作，我可能会从零开始。我的猜测是，自从编写应用程序以来，您已经学到了很多关于设计和架构的知识--所以您最好利用这个机会编写一个更易于维护的应用程序。(你可能还会知道，在最初的应用程序中，哪些设计决策最终是错误的。)|1227768|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you just need to fix a bug, and it's a reasonably simple bug, and you don't anticipate much more work beyond that - stick with VB5. Anything else will introduce far more work.

However, if this is really a "live" product which you expect to work on a lot in the future, I would probably start from scratch. My guess is that you've learned a lot about design and architecture since writing the app - so you might as well take the opportunity to write a more maintainable app. (You'll also probably have learned which design decisions in the original app ended up being mistakes.)

I've got a contract where I have to continue the development of and old application suite that was programmed in VB5 back in the days.

I've bug to fix and new feature to develop.

So I have a few choices:

<ol>
<li>Keep programming in VB5
(NOOOOOOOOOOOOOOO!!!!)</li>
<li>Convert VB5 to C# (How??? Is it
possible without going insane?)</li>
<li>Rewrite the whole application suite
(Very time consuming)</li>
</ol>

Is there any other choices? What should I do?

EDIT: Ah and also, it relies on an ACCESS database which I'd like to move to SQL EXPRESS. Because it's a crazy database made illogically by a stupid programmer from the '90s lol.

Thanks

Less time consuming : Rewriting or converting an app from VB5 to C#

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我有一个合同，我必须继续开发和旧的应用程序套件，这是在VB5编程的日子里。我有bug需要修复，新特性需要开发。所以我有几个选择：继续用VB5编程(！)将VB5转换为C# (如何？)不可能不发疯吗？)重写整个应用程序套件(非常耗时)还有别的选择吗？我该怎么办？编辑:啊，而且，它依赖于ACCESS数据库，我想移到SQL。因为这是一个不符合逻辑的数据库，是90年代的一个愚蠢的程序员做的。谢谢

问节省时间:重写或将应用程序从VB5转换为C#
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问节省时间:重写或将应用程序从VB5转换为C#EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问节省时间:重写或将应用程序从VB5转换为C#
EN