Here is an adaptation of a couple of my answers to similar questions.
Converting automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.
...and here's a blog post by a Microsofty that agrees with me:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
This excellent Microsoft page recommends two third party migration tools as better than the (no longer available) built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. I believe they have some support for common third-party controls and DLLs - Artinsoft suport these. It would be worth contacting them with a list of your dependencies. VBMigration has a free tool that will list the dependencies for just this reason. Also worth contacting the original vendors in the hope of a .NET equivalent.
The Microsoft page also says:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
There are many more C# developers than VB.NET developers on Stack Overflow, so you will probably get several answers recommending C#. Also historically Microsoft has tended to support C# more enthusiastically in terms of code examples for new parts of .NET and so on. But Microsoft does now assure us that:
Both [C# and VB.NET] are first-class programming languages that are based on the Microsoft .NET Framework, and they are equally powerful.
So it's a personal decision whether you want to choose C# or VB.NET. The Artinsoft tool claims it can convert VB6 to C#.
EDIT: I just found another offering - NewCode - through an ad on a programming website!
My snap judgement is that the website isn't as detailed as the two competitors I've written about above. That may be unfair. Some guy at Microsoft Ireland blogged about them - I think they are based in Ireland. Apparently the tool converts your VB6 to a DSL and then to VB.NET Winforms, C#, WPF, Java...
C# 和 VB.NET 之间的选择在很大程度上是次要的。 两者都有一些小优点，但总的来说，您可以用任何一个来做大多数事情。 如果您需要 COM 互操作，那么 VB.NET 可能会很有用（无论是对于所有内容，还是仅对于特定程序集） - 但 C# 4.0（在 VS2010 中）将通过新的动态类型和功能来填补这一空白无 PIA 变化。 总的来说，我非常更喜欢 C#，但这必须是本地决定。
Upgrading; even if mechanical tools exist, this will not really do much for you. It won't make it magically well-suited to .NET, or make much decent use of the framework. I'd always prefer a re-write in this scenario, but that does have associated risks / costs. For example, some colleagues of mine are currently re-writing some VB6/ASP/COM+/xslt code to use ASP.NET MVC - most of the "interesting" code is actually business logic, which isn't massively hard to port (the trick is testing it ;-p). It helps that the layout of our VB6 code is granular, allowing us to migrate individual slices, without having to push the whole lot at once.
The 3rd party controls will be a nuisance, and it sounds like the other dlls might have to be reverse engineered. Not trivial.
The choice between C# and VB.NET is largely secondary. Both have some minor advantages, but overall you can do most things with either. If you need COM interop, then VB.NET might be useful (either for everything, or for just a specific assembly) - but C# 4.0 (in VS2010) will plug this gap via the new dynamic typing and the no-PIA changes. Overall, I vastly prefer C#, but that has to be a local decision.
The first and most important step is make your existing application as .NET like you can. Anything VB6 specific or relies on a 3rd party control get as much of it behind interfaces as you can. The interface will show exactly what you are using the 3rd party stuff for and what behaviors first. By doing this in VB6 first you can run unit and integration tests make sure that behavior is PRESERVED. That the key element that the behavior of your application is preserved.
As for the issue between C# and VB.NET. There is functionally little difference between the two languages. One of my conversion project back in the 90s was taking my Company's CAD/CAM application from a BASIC dialect known as Rocky Mountain BASIC into Visual Basic 3. We had a few false start before that and it was felt and later proven to us that it is far easier to preserve behavior by switching to another BASIC family langauge than to convert over a completely different language family like C.
Understand in our circumstance we have a lot of math heavy subroutines and math is one of the few areas that remains relativity consistent over the BASIC family of languages. So my experience my not be a 100% applicable to your case.
It is my opinion that the terseness of C style languages is a detriment to long term maintainability (decades). However to be fair it is a minor point at best. I have extensive experience in both languages as I write and maintain a simulation of Mercury and Gemini Space Capsule written in C++ with some utilities written in C# in addition to the CAD/CAM program in VB6/VB.NET for my company.
Right now our .NET conversion is focused on VB.NET. I found automated tools near useless as we are a heavy graphics oriented program. Luckily we don't use the VB Graphics calls directly but put everything behind a canvas interface. For printing compatibility we use the Printer Compatibility Library from the VB Power Pack as a starting point.
We have a tool that we run our code through that converts all integers to type Int16 and all longs to type Int32 plus a few other commonly done conversion. Then we place the converted class or routine into our .NET library and run unit tests. The results are compared to the same tests ran on the original VB6 code.
The biggest pain in the butt has been the forms. Simple dialog are OK but for the more complex forms we just have to reimplement. Again our forms lies behind interfaces in our original code so while it is work it is straightforward for us to see what to do.
My guess is that it is a database app. See if you can rewrite some features by directly talking to DB. Don't worry about having users use two app. The old app is bad enough for them to ask for an update.
My other guess is that since it is VB6, it doesn't have very good UI/BusinessLogic separation. That is why auto upgrading will not get you too much.
Maybe I was wrong about your situation. You need to ask you how much you really can get out of the existing code. Buy/Read Michael Feather's Legacy code book too.
I have started reworking one of my company's apps written in VB6 to VB.NET. Both C# and VB.NET rely on the .NET framework, and the differences between an app compiled in either one is negligible. Choose the language you and others working on the project feel more comfortable with. One advantage to using VB.NET (though I am hesitant to call it such) is you can use the "Upgrade Visual Basic 6 Code" feature in Visual Studio. There are some things the converter fixes, and a lot it doesn't. If you want to try this, you'll have to clean up your VB6 code:
All arrays need to be zero based
Avoid using fixed length strings if at all possible. This code will have to be changed to use Char arrays in vb.net
Explicitly declare all variables. Use Option Explicit if you don't already
Avoid variants like the plague, unless you absolutely must use one for an API call
Specify ByRef or ByVal when passing parameters, don't rely on default behavior for this
Always specify what property you are changing, default properties do not exist in vb.net. For example "txtName = strName" becomes "txtName.Text = strName"
A much more detailed list of these differences can be found here
Even after cleaning up existing code the best you can, the conversion still isn't 100%. You could try this in a separate project just to see what you get to give you ideas on how things need to be reworked. Sometimes forms look ugly after a conversion as well, and for some things you may well end up redoing them from scratch anyway.
A lot of our forms made heavy use of the ItemData property in combo boxes and list boxes which no longer exists in .NET. ListViews also work differently, and none of the drawing functions are the same. Some forms from the app I converted just looked really bad when converted to .NET controls and didn't behave the same way, so I'm just going to end up reworking these from scratch. The advantage is I get to rework processes that were not very efficient to begin with, but of course this takes a lot more time. Couple that with the fact I am still learning learning what the various .NET libraries do... yeah it's going to take a while.
As it's pointed out, you could rewrite your application.
Another solution will be a true VB6 alternative, full compatible. I'm working in a project that want to be a real VB 7: RAD Basic. You could continue working with your VB6 code base in a modern environment.
c) 庆祝这应该是有史以来最简单的新建应用程序开发项目，因为您有技术经验丰富的人来指导您，您有成熟的工具来构建应用程序，并且有一组明确定义的需求，所以您知道到底要构建什么。
PS 在这一点上我不会打扰 Winforms。 我会直接跳到 WPF，稍后您会感谢我的。
PPS 语言真的不重要（C# 或 VB.Net）。 努力将是一样的。
You are not going to like my answer but here goes.
a) Hire someone with a significant amount of experience in building large .Net applications to come and guide the project and teach you.
b) Extract the business requirements from your current application and freeze them.
c) Celebrate the fact that this should be the easiest greenfield application development project ever because you have someone with experience in the technology to guide you, you have mature tools to build the application with and have a well defined set of requirements, so you know exactly what to build.
P.S. At this point I would not bother with Winforms. I would jump straight to WPF, you'll thank me later.
P.P.S The language really does not matter (C# or VB.Net). The effort will be the same.
VB6 还可以通过 COM 轻松扩展。 目前正在使用数百种不同的 COM API，这还不包括通常成为企业系统一部分的所有内部组件。 转换器必须能够识别 VB6 在 UI 设计和代码中使用的任何 COM 类或控件，并使用其他适当的 .NET API 或互操作来表达它。 我知道的一种工具甚至可以从 VB6 中的 COM 使用信息生成 .NET 代码框架。 工业强度的转换工具将具有强大的可扩展的 COM 类型系统，并允许用户控制在生成的代码中如何替换 COM。
The question is explicitly asking for information about the “Best Development tools for Upgrading from VB6.0” for a large, complex VB6/COM upgrade and second about C# or VB.NET.
A perfect “conversion” tool would help you meet the two critical goals of every upgrade
Preserving functionality
Taking advantage of .NET in a way that follows your desired coding and platform dependency standards
The Tool’s role in Preserving Functionality
Large, mature legacy systems can contain thousands of code files and millions of lines of code. The effort required to fully describe and verify the functionality embodied in that much code is massive. In fact, there can be so much functional work that some technical-minded teams fail to see it at first. They spend most of their time worrying about how to take advantage of the latest .NET design, language, and framework features before they fully appreciate just how difficult it will be to preserve and verify the legacy functionality. It’s like they are fishing from the back of a huge functionality whale while worrying about catching little technical fish.
Teams that try to reproduce a mountain of code by reading, interpreting, and recoding it manually may well go blind in the process… So a critical feature of any conversion tool is to help the team read, interpret, and rewrite their code while rewriting it in a form that preserves its semantics. Computer scientists have studied the problem of reading interpreting, and rewriting source code for over 60 years and the solution they came up with is called a compiler. An effective code “converter” works like a compiler.
VB6 is a high level language: the Microsoft VB6 compiler and its runtime did myriad things implicitly: managing type inference, implicit conversions, implicit by ref, late-bound calls, dealing with nulls, goto-style error handling, designing forms, etc. A VB6 converter must also be able to recognize and store the myriad little details not explicitly in the code and it must be able to correctly express those details in .NET. An industrial strength conversion tool will have a powerful, extensible VB6 metalanguage system that allows the user to control how VB6 code is recognized and interpreted.
VB6 is also easily extensible through COM. There are many hundreds of different COM APIs in use, and that is not counting all the in-house components that typically become part of enterprise systems. The converter must be able to recognize any COM class or control used by the VB6, both in UI design and in code and express it using some other appropriate .NET API or interop. One tool I know of can even generate a .NET code framework from the COM usage information in the VB6. An industrial strength conversion tool will have a powerful COM type system that is extensible and allows the user to control how COM is replaced in the generated code.
The Tool’s role in Taking advantage of .NET
VB6 and .NET are different in many ways and so are the various APIs that support the two platforms. So, with tools or without, there will almost always be some re-design required. Furthermore, each team brings different preferences, constraints, and requirements to their project: ask 10 programs how to code something and you will get at least 10 different answers. The converter must be help the team express its unique preferences, constraints, and requirements. This includes providing repeatable, self-documenting means of modifying VB6 code before it is processed, modifying .NET code after it is generated, integrating hand written code, describing custom API replacements, directing custom code restructuring, and doing many other various dynamic and project-specific transformations as required.
Putting it all together
A large upgrade is rarely fully predicted and planned in advance. Even with extensive knowledge of both the source code and the desired .NET coding standards, there will be many problems and opportunities that emerge during the work. The source code and requirements must be allowed to change during the upgrade project. What is needed is an agile methodology that allows the team to adapt to source code changes, experiment with different .NET coding techniques, respond to a deeper understanding of requirements, and incrementally improve their automated upgrade process over time. An industrial strength conversion tool will have the accuracy, precision, flexibility and speed to enable this type of methodology.
One more comment about Conversion tools. The most important ”tool” you will use in a .NET upgrade is your brain. You must learn .NET languages, design-patterns, and frameworks and apply what you know in your upgrade effort. The best automated tool does not decide for you how to rewrite your code: it helps you re-implement the legacy functionality according to the design you decide makes sense.
When I ask the .NET community (i.e. search the web) for information, tools, ideas, code, and help with programming problems, I am much more likely to find answers expressed in C# than in VB.NET. I also find the C# compiler is a better fit for a tool-assisted rewrite because it requires the generated code to be more internally consistent and explicitly described. Getting and keeping the build is a somewhat crude, but absolutely critical test of code quality and a key milestone in any upgrade effort. Remember that VB.NET is not VB6. This sounds obvious, but it can be hard to keep in mind because the two language look similar. This similarity can be deceiving; so IMO it is better to go to C# where you are reminded that the rules are different. Finally, C# has always been and continues to be designed for .NET; VB.NET cannot say that.
Disclaimer: I work for Great Migrations. There is a lot more to discuss. Please visit Great Migrations Documentation Portal for more articles and to get the gmStudio Trial and try an industrial strength upgrade tool for yourself.
发布评论
评论（8）
这是的改编几个我的类似问题的回答。
自动转换是比重写更好的选择。 一个常见的陷阱是开始乐观地重写一个大型软件，在修复旧架构中的一些众所周知的缺陷方面取得良好的早期进展，然后陷入多年来你认为理所当然的功能中。 此时，您的管理层开始变得焦躁不安，一切都会变得非常不舒服。
...这是 Microsofty 的一篇博客文章 同意我的观点：
这个优秀的 Microsoft 页面 推荐了两个第三方迁移工具比（不再可用）构建的更好- 在 VB.NET 升级向导中 - Artinsoft 和 CodeArchitects VBMigration。 我相信他们对常见的第三方控件和 DLL 有一些支持 - Artinsoft 支持 这些。 值得联系他们并提供您的依赖项列表。 VBMigration 有一个免费工具，它会出于这个原因列出依赖项。 还值得联系原始供应商，希望获得 .NET 等效版本。
微软页面还说：
Stack Overflow 上的 C# 开发人员比 VB.NET 开发人员多得多，因此您可能会得到几个推荐 C# 的答案。 另外，从历史上看，Microsoft 倾向于在 .NET 新部分的代码示例等方面更加热情地支持 C#。 但微软现在向我们保证：
因此，选择 C# 还是 VB.NET 完全是个人决定。 Artinsoft 工具声称可以将 VB6 转换为 C#。
编辑：我刚刚通过编程网站上的广告找到了另一个产品 - NewCode！
我的快速判断是该网站不如我上面写的两个竞争对手那么详细。 这可能不公平。 微软爱尔兰的一些人 博客介绍了他们 - 我认为他们位于爱尔兰。 显然，该工具将您的 VB6 转换为 DSL，然后转换为 VB.NET Winforms、C#、WPF、Java...
Here is an adaptation of a couple of my answers to similar questions.
Converting automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.
...and here's a blog post by a Microsofty that agrees with me:
This excellent Microsoft page recommends two third party migration tools as better than the (no longer available) built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. I believe they have some support for common third-party controls and DLLs - Artinsoft suport these. It would be worth contacting them with a list of your dependencies. VBMigration has a free tool that will list the dependencies for just this reason. Also worth contacting the original vendors in the hope of a .NET equivalent.
The Microsoft page also says:
There are many more C# developers than VB.NET developers on Stack Overflow, so you will probably get several answers recommending C#. Also historically Microsoft has tended to support C# more enthusiastically in terms of code examples for new parts of .NET and so on. But Microsoft does now assure us that:
So it's a personal decision whether you want to choose C# or VB.NET. The Artinsoft tool claims it can convert VB6 to C#.
EDIT: I just found another offering - NewCode - through an ad on a programming website!
My snap judgement is that the website isn't as detailed as the two competitors I've written about above. That may be unfair. Some guy at Microsoft Ireland blogged about them - I think they are based in Ireland. Apparently the tool converts your VB6 to a DSL and then to VB.NET Winforms, C#, WPF, Java...
升级； 即使存在机械工具，这对你来说也没有多大作用。 它不会让它神奇地非常适合.NET，或者很好地利用该框架。 在这种情况下，我总是更喜欢重写，但这确实有相关的风险/成本。 例如，我的一些同事目前正在重写一些 VB6/ASP/COM+/xslt 代码以使用 ASP.NET MVC - 大多数“有趣”的代码实际上是业务逻辑，这并不是很难移植（技巧是测试它；-p)。 VB6 代码的布局是细粒度的，这有助于我们迁移各个片段，而不必一次推送整个片段。
3rd 方控件会很麻烦，而且听起来其他 dll 可能必须进行逆向工程。 不是微不足道的。
C# 和 VB.NET 之间的选择在很大程度上是次要的。 两者都有一些小优点，但总的来说，您可以用任何一个来做大多数事情。 如果您需要 COM 互操作，那么 VB.NET 可能会很有用（无论是对于所有内容，还是仅对于特定程序集） - 但 C# 4.0（在 VS2010 中）将通过新的
动态类型和功能来填补这一空白无 PIA 变化。 总的来说，我非常更喜欢 C#，但这必须是本地决定。Upgrading; even if mechanical tools exist, this will not really do much for you. It won't make it magically well-suited to .NET, or make much decent use of the framework. I'd always prefer a re-write in this scenario, but that does have associated risks / costs. For example, some colleagues of mine are currently re-writing some VB6/ASP/COM+/xslt code to use ASP.NET MVC - most of the "interesting" code is actually business logic, which isn't massively hard to port (the trick is testing it ;-p). It helps that the layout of our VB6 code is granular, allowing us to migrate individual slices, without having to push the whole lot at once.
The 3rd party controls will be a nuisance, and it sounds like the other dlls might have to be reverse engineered. Not trivial.
The choice between C# and VB.NET is largely secondary. Both have some minor advantages, but overall you can do most things with either. If you need COM interop, then VB.NET might be useful (either for everything, or for just a specific assembly) - but C# 4.0 (in VS2010) will plug this gap via the new
dynamictyping and the no-PIA changes. Overall, I vastly prefer C#, but that has to be a local decision.我在这里谈论这个问题这里
第一步也是最重要的一步是让您现有的应用程序尽可能成为 .NET。 任何特定于 VB6 或依赖于第 3 方控件的内容都尽可能多地位于界面后面。 该界面将准确显示您使用 3rd 方内容的用途以及首先的行为。 通过首先在 VB6 中执行此操作，您可以运行单元和集成测试，以确保行为得到保留。 保留应用程序行为的关键元素。
至于C#和VB.NET之间的问题。 这两种语言在功能上几乎没有区别。 早在 90 年代，我的一个转换项目就是将我公司的 CAD/CAM 应用程序从称为 Rocky Mountain BASIC 的 BASIC 方言转换为 Visual Basic 3。在此之前，我们有过一些错误的开始，我们感觉到并后来向我们证明了它通过切换到另一种 BASIC 家族语言比转换完全不同的语言家族（如 C）来保留行为要容易得多。请
理解，在我们的情况下，我们有很多数学繁重的子例程，而数学是少数几个保持相对论一致的领域之一BASIC 语言家族。 所以我的经验不能100%适用于你的情况。
我认为 C 风格语言的简洁性不利于长期（数十年）的可维护性。 但公平地说，这充其量只是一个小问题。 我在这两种语言上都拥有丰富的经验，因为我为我的公司编写和维护了用 C++ 编写的水星和双子座太空舱的模拟，以及一些用 C# 编写的实用程序以及 VB6/VB.NET 中的 CAD/CAM 程序。
现在我们的.NET 转换主要集中在VB.NET。 我发现自动化工具几乎毫无用处，因为我们是一个面向图形的重型程序。 幸运的是，我们不直接使用 VB Graphics 调用，而是将所有内容放在画布界面后面。 为了实现打印兼容性，我们使用 VB Power Pack 中的打印机兼容性库作为起点。
我们有一个运行代码的工具，可以将所有整数转换为 Int16 类型，将所有长整型转换为 Int32 类型，再加上一些其他常见的转换。 然后，我们将转换后的类或例程放入 .NET 库中并运行单元测试。 将结果与在原始 VB6 代码上运行的相同测试进行比较。
屁股上最大的痛苦是形式。 简单的对话框是可以的，但对于更复杂的表单，我们只需要重新实现。 同样，我们的表单位于原始代码中的接口后面，因此当它工作时，我们很容易看到要做什么。
I talk about this issue here
The first and most important step is make your existing application as .NET like you can. Anything VB6 specific or relies on a 3rd party control get as much of it behind interfaces as you can. The interface will show exactly what you are using the 3rd party stuff for and what behaviors first. By doing this in VB6 first you can run unit and integration tests make sure that behavior is PRESERVED. That the key element that the behavior of your application is preserved.
As for the issue between C# and VB.NET. There is functionally little difference between the two languages. One of my conversion project back in the 90s was taking my Company's CAD/CAM application from a BASIC dialect known as Rocky Mountain BASIC into Visual Basic 3. We had a few false start before that and it was felt and later proven to us that it is far easier to preserve behavior by switching to another BASIC family langauge than to convert over a completely different language family like C.
Understand in our circumstance we have a lot of math heavy subroutines and math is one of the few areas that remains relativity consistent over the BASIC family of languages. So my experience my not be a 100% applicable to your case.
It is my opinion that the terseness of C style languages is a detriment to long term maintainability (decades). However to be fair it is a minor point at best. I have extensive experience in both languages as I write and maintain a simulation of Mercury and Gemini Space Capsule written in C++ with some utilities written in C# in addition to the CAD/CAM program in VB6/VB.NET for my company.
Right now our .NET conversion is focused on VB.NET. I found automated tools near useless as we are a heavy graphics oriented program. Luckily we don't use the VB Graphics calls directly but put everything behind a canvas interface. For printing compatibility we use the Printer Compatibility Library from the VB Power Pack as a starting point.
We have a tool that we run our code through that converts all integers to type Int16 and all longs to type Int32 plus a few other commonly done conversion. Then we place the converted class or routine into our .NET library and run unit tests. The results are compared to the same tests ran on the original VB6 code.
The biggest pain in the butt has been the forms. Simple dialog are OK but for the more complex forms we just have to reimplement. Again our forms lies behind interfaces in our original code so while it is work it is straightforward for us to see what to do.
我建议您“部分重写”您的应用程序。 这种方法的奇特名称是绞杀（http://martinfowler.com/bliki/StranglerApplication.html）。
我的猜测是它是一个数据库应用程序。 看看是否可以通过直接与数据库对话来重写一些功能。 不用担心用户使用两个应用程序。 旧的应用程序太糟糕了，他们要求更新。
我的另一个猜测是，由于它是 VB6，因此它没有很好的 UI/BusinessLogic 分离。 这就是为什么自动升级不会给你带来太多好处。
也许我对你的情况的理解是错误的。 您需要问自己真正可以从现有代码中获得多少收益。 也购买/阅读 Michael Feather 的 Legacy 密码书。
I would suggest you 'partially rewrite' you application. The fancy name for this approach is strangling (http://martinfowler.com/bliki/StranglerApplication.html).
My guess is that it is a database app. See if you can rewrite some features by directly talking to DB. Don't worry about having users use two app. The old app is bad enough for them to ask for an update.
My other guess is that since it is VB6, it doesn't have very good UI/BusinessLogic separation. That is why auto upgrading will not get you too much.
Maybe I was wrong about your situation. You need to ask you how much you really can get out of the existing code. Buy/Read Michael Feather's Legacy code book too.
我已经开始将公司用 VB6 编写的应用程序之一重新设计为 VB.NET。 C# 和 VB.NET 都依赖于 .NET 框架，并且在任一版本中编译的应用程序之间的差异可以忽略不计。 选择您和参与该项目的其他人感觉更舒服的语言。 使用 VB.NET 的一个优点（尽管我不太愿意这样称呼它）是您可以使用 Visual Studio 中的“升级 Visual Basic 6 代码”功能。 转换器修复了一些问题，也修复了很多问题。 如果您想尝试此操作，则必须清理 VB6 代码：
即使在尽最大努力清理现有代码之后，转化率仍然不是 100%。 您可以在一个单独的项目中尝试此操作，看看您能得到什么，从而为您提供有关如何重新设计事物的想法。 有时，转换后的表单看起来也很难看，对于某些事情，您最终可能会从头开始重做它们。
我们的许多表单在组合框和列表框中大量使用了 ItemData 属性，而这些属性在 .NET 中已不再存在。 ListView 的工作方式也不同，并且绘图功能都不相同。 我转换的应用程序中的某些表单在转换为 .NET 控件时看起来非常糟糕，并且行为方式也不同，因此我最终将重新设计这些表单。 优点是我可以重新设计原本效率不高的流程，但这当然需要更多时间。 再加上我仍在学习各种 .NET 库的功能……是的，这需要一段时间。
I have started reworking one of my company's apps written in VB6 to VB.NET. Both C# and VB.NET rely on the .NET framework, and the differences between an app compiled in either one is negligible. Choose the language you and others working on the project feel more comfortable with. One advantage to using VB.NET (though I am hesitant to call it such) is you can use the "Upgrade Visual Basic 6 Code" feature in Visual Studio. There are some things the converter fixes, and a lot it doesn't. If you want to try this, you'll have to clean up your VB6 code:
Even after cleaning up existing code the best you can, the conversion still isn't 100%. You could try this in a separate project just to see what you get to give you ideas on how things need to be reworked. Sometimes forms look ugly after a conversion as well, and for some things you may well end up redoing them from scratch anyway.
A lot of our forms made heavy use of the ItemData property in combo boxes and list boxes which no longer exists in .NET. ListViews also work differently, and none of the drawing functions are the same. Some forms from the app I converted just looked really bad when converted to .NET controls and didn't behave the same way, so I'm just going to end up reworking these from scratch. The advantage is I get to rework processes that were not very efficient to begin with, but of course this takes a lot more time. Couple that with the fact I am still learning learning what the various .NET libraries do... yeah it's going to take a while.
正如所指出的，您可以重写您的应用程序。
另一个解决方案将是真正的 VB6 替代方案，完全兼容。 我正在从事一个项目，希望成为真正的 VB 7：RAD Basic。 您可以继续在现代环境中使用 VB6 代码库。
As it's pointed out, you could rewrite your application.
Another solution will be a true VB6 alternative, full compatible. I'm working in a project that want to be a real VB 7: RAD Basic. You could continue working with your VB6 code base in a modern environment.
你不会喜欢我的回答，但就这样吧。
a) 聘请在构建大型 .Net 应用程序方面具有丰富经验的人员来指导项目并指导您。
b) 从当前应用程序中提取业务需求并冻结它们。
c) 庆祝这应该是有史以来最简单的新建应用程序开发项目，因为您有技术经验丰富的人来指导您，您有成熟的工具来构建应用程序，并且有一组明确定义的需求，所以您知道到底要构建什么。
PS 在这一点上我不会打扰 Winforms。 我会直接跳到 WPF，稍后您会感谢我的。
PPS 语言真的不重要（C# 或 VB.Net）。 努力将是一样的。
You are not going to like my answer but here goes.
a) Hire someone with a significant amount of experience in building large .Net applications to come and guide the project and teach you.
b) Extract the business requirements from your current application and freeze them.
c) Celebrate the fact that this should be the easiest greenfield application development project ever because you have someone with experience in the technology to guide you, you have mature tools to build the application with and have a well defined set of requirements, so you know exactly what to build.
P.S. At this point I would not bother with Winforms. I would jump straight to WPF, you'll thank me later.
P.P.S The language really does not matter (C# or VB.Net). The effort will be the same.
该问题明确询问有关“从 VB6.0 升级的最佳开发工具”的信息，以进行大型、复杂的 VB6/COM 升级，其次询问有关 C# 或 VB.NET 的信息。
完美的“转换”工具将帮助您实现每次升级的两个关键目标
遵循您所需的编码和平台依赖性标准
该工具在保留功能方面的作用
大型、成熟的遗留系统可以包含数千个代码文件和数百万行代码。 完全描述和验证这么多代码中包含的功能所需的工作量是巨大的。 事实上，可能存在如此多的功能性工作，以至于一些具有技术头脑的团队一开始都看不到它。 他们大部分时间都在担心如何利用最新的 .NET 设计、语言和框架功能，然后才完全意识到保留和验证遗留功能有多么困难。 这就像他们在一头巨大的功能性鲸鱼的背上钓鱼，同时担心捕捉到一些技术性的小鱼。
试图通过手动阅读、解释和重新编码来重现堆积如山的代码的团队很可能会在这个过程中陷入盲目……因此任何转换工具的一个关键功能是帮助团队在重写代码的同时阅读、解释和重写代码以保留其语义的形式。 计算机科学家对读取解释和重写源代码的问题进行了 60 多年的研究，他们提出的解决方案称为编译器。 有效的代码“转换器”就像编译器一样工作。
VB6 是一种高级语言：Microsoft VB6 编译器及其运行时隐式执行了无数操作：管理类型推断、隐式转换、引用隐式、后期绑定调用、处理 null、goto 式错误处理、设计表单等。 VB6 转换器还必须能够识别和存储代码中未明确显示的无数小细节，并且它必须能够在 .NET 中正确表达这些细节。 工业强度转换工具将具有强大的、可扩展的VB6元语言系统，允许用户控制VB6代码的识别和解释方式。
VB6 还可以通过 COM 轻松扩展。 目前正在使用数百种不同的 COM API，这还不包括通常成为企业系统一部分的所有内部组件。 转换器必须能够识别 VB6 在 UI 设计和代码中使用的任何 COM 类或控件，并使用其他适当的 .NET API 或互操作来表达它。 我知道的一种工具甚至可以从 VB6 中的 COM 使用信息生成 .NET 代码框架。 工业强度的转换工具将具有强大的可扩展的 COM 类型系统，并允许用户控制在生成的代码中如何替换 COM。
该工具在利用 .NET 中的作用
VB6 和 .NET 在很多方面都不同，支持这两个平台的各种 API 也不同。 因此，无论有没有工具，几乎总是需要进行一些重新设计。 此外，每个团队都会为其项目带来不同的偏好、约束和要求：询问 10 个程序如何编码，您将得到至少 10 个不同的答案。 转换器必须帮助团队表达其独特的偏好、约束和要求。 这包括提供可重复的、自记录的方法，用于在处理 VB6 代码之前修改它、在生成 .NET 代码之后修改它、集成手写代码、描述自定义 API 替换、指导自定义代码重组以及执行许多其他各种动态和项目- 根据需要进行特定转换。
综合考虑
大型升级很少能提前完全预测和计划。 即使对源代码和所需的 .NET 编码标准有广泛的了解，工作过程中也会出现许多问题和机会。 必须允许源代码和要求在升级项目期间发生更改。 我们需要的是一种敏捷的方法，允许
团队适应源代码更改，尝试不同的 .NET 编码技术，响应对需求的更深入理解，并随着时间的推移逐步改进其自动升级过程。 工业强度转换工具将具有实现此类方法的准确性、精确性、灵活性和速度。
关于转换工具的另一条评论。 您在 .NET 升级中使用的最重要的“工具”是您的大脑。 您必须学习 .NET 语言、设计模式和框架，并在升级工作中应用您所知道的知识。 最好的自动化工具不会为您决定如何重写代码：它可以帮助您根据您认为有意义的设计重新实现遗留功能。
Microsoft 在本文中推荐了几种工具。 VB6 升级合作伙伴工具
VB.NET 或 C#< /strong>
当我向 .NET 社区（即搜索 Web）询问有关编程问题的信息、工具、想法、代码和帮助时，我更有可能找到用 C# 表达的答案，而不是用 VB.NET 表达的答案。 我还发现 C# 编译器更适合工具辅助重写，因为它要求生成的代码内部更加一致且描述更加明确。 获取和保留构建是对代码质量的一个有点粗糙但绝对关键的测试，也是任何升级工作中的一个关键里程碑。 请记住，VB.NET 不是 VB6。 这听起来很明显，但可能很难记住，因为这两种语言看起来很相似。 这种相似性可能具有欺骗性。 因此，IMO 最好转到 C#，那里会提醒您规则不同。 最后，C# 一直并将继续是为 .NET 设计的； VB.NET 不能这么说。
免责声明：我为大迁徙工作。 还有很多事情需要讨论。 请访问Great Migrations文档门户获取更多文章并获取gmStudio试用版，亲自尝试工业强度升级工具。
The question is explicitly asking for information about the “Best Development tools for Upgrading from VB6.0” for a large, complex VB6/COM upgrade and second about C# or VB.NET.
A perfect “conversion” tool would help you meet the two critical goals of every upgrade
that follows your desired coding and platform dependency standards
The Tool’s role in Preserving Functionality
Large, mature legacy systems can contain thousands of code files and millions of lines of code. The effort required to fully describe and verify the functionality embodied in that much code is massive. In fact, there can be so much functional work that some technical-minded teams fail to see it at first. They spend most of their time worrying about how to take advantage of the latest .NET design, language, and framework features before they fully appreciate just how difficult it will be to preserve and verify the legacy functionality. It’s like they are fishing from the back of a huge functionality whale while worrying about catching little technical fish.
Teams that try to reproduce a mountain of code by reading, interpreting, and recoding it manually may well go blind in the process… So a critical feature of any conversion tool is to help the team read, interpret, and rewrite their code while rewriting it in a form that preserves its semantics. Computer scientists have studied the problem of reading interpreting, and rewriting source code for over 60 years and the solution they came up with is called a compiler. An effective code “converter” works like a compiler.
VB6 is a high level language: the Microsoft VB6 compiler and its runtime did myriad things implicitly: managing type inference, implicit conversions, implicit by ref, late-bound calls, dealing with nulls, goto-style error handling, designing forms, etc. A VB6 converter must also be able to recognize and store the myriad little details not explicitly in the code and it must be able to correctly express those details in .NET. An industrial strength conversion tool will have a powerful, extensible VB6 metalanguage system that allows the user to control how VB6 code is recognized and interpreted.
VB6 is also easily extensible through COM. There are many hundreds of different COM APIs in use, and that is not counting all the in-house components that typically become part of enterprise systems. The converter must be able to recognize any COM class or control used by the VB6, both in UI design and in code and express it using some other appropriate .NET API or interop. One tool I know of can even generate a .NET code framework from the COM usage information in the VB6. An industrial strength conversion tool will have a powerful COM type system that is extensible and allows the user to control how COM is replaced in the generated code.
The Tool’s role in Taking advantage of .NET
VB6 and .NET are different in many ways and so are the various APIs that support the two platforms. So, with tools or without, there will almost always be some re-design required. Furthermore, each team brings different preferences, constraints, and requirements to their project: ask 10 programs how to code something and you will get at least 10 different answers. The converter must be help the team express its unique preferences, constraints, and requirements. This includes providing repeatable, self-documenting means of modifying VB6 code before it is processed, modifying .NET code after it is generated, integrating hand written code, describing custom API replacements, directing custom code restructuring, and doing many other various dynamic and project-specific transformations as required.
Putting it all together
A large upgrade is rarely fully predicted and planned in advance. Even with extensive knowledge of both the source code and the desired .NET coding standards, there will be many problems and opportunities that emerge during the work. The source code and requirements must be allowed to change during the upgrade project. What is needed is an agile methodology that allows the
team to adapt to source code changes, experiment with different .NET coding techniques, respond to a deeper understanding of requirements, and incrementally improve their automated upgrade process over time. An industrial strength conversion tool will have the accuracy, precision, flexibility and speed to enable this type of methodology.
One more comment about Conversion tools. The most important ”tool” you will use in a .NET upgrade is your brain. You must learn .NET languages, design-patterns, and frameworks and apply what you know in your upgrade effort. The best automated tool does not decide for you how to rewrite your code: it helps you re-implement the legacy functionality according to the design you decide makes sense.
Microsoft suggests several tools in this article. VB6 Upgrade Partner Tools
VB.NET or C#
When I ask the .NET community (i.e. search the web) for information, tools, ideas, code, and help with programming problems, I am much more likely to find answers expressed in C# than in VB.NET. I also find the C# compiler is a better fit for a tool-assisted rewrite because it requires the generated code to be more internally consistent and explicitly described. Getting and keeping the build is a somewhat crude, but absolutely critical test of code quality and a key milestone in any upgrade effort. Remember that VB.NET is not VB6. This sounds obvious, but it can be hard to keep in mind because the two language look similar. This similarity can be deceiving; so IMO it is better to go to C# where you are reminded that the rules are different. Finally, C# has always been and continues to be designed for .NET; VB.NET cannot say that.
Disclaimer: I work for Great Migrations. There is a lot more to discuss. Please visit Great Migrations Documentation Portal for more articles and to get the gmStudio Trial and try an industrial strength upgrade tool for yourself.