blocks|key|395110|text|我们也有一个要移植到.NET的VB6应用程序，并且我们使用COM-Interop策略。所有的新功能都可以在.NET中实现，只有图形用户界面的东西仍然是VB；同时，我们可以独立开发一个新的图形用户界面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|395111|如果您还不知道这一点，您可以使用免注册的COM互操作在不使用注册表的情况下进行COM互操作(因为这会给我们带来一些问题|offset|length|style|BOLD|395112|395113|MSDN+Documentation|unordered-list-item|395114|Manifest-Creator+(very+useful!)|395115|395116|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/fh1h056h.aspx|1|http://blogs.msdn.com/junfeng/archive/2007/04/14/genman32-a-tool-to-generate-sxs-manifest-for-managed-assembly-for-registration-free-com-net-interop.aspx^0|0|H|9|0|0|0|I|0|0|0|V|1|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|L|3|M|5|K|7|17|8|@]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|N|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

We have a VB6 application which is being ported to .NET either, and we use the COM-Interop strategy. All new features can be implemented in .NET, only the GUI-stuff remains VB; at the same time, we can develop a new GUI independently. 

If you don't already know this, you can do COM Interop without using the registry (as this caused some problems for us) with Registration-Free COM Interop:

<ul>
<li><a href="http://msdn.microsoft.com/en-us/library/fh1h056h.aspx" rel="nofollow noreferrer">MSDN Documentation</a></li>
<li><a href="http://blogs.msdn.com/junfeng/archive/2007/04/14/genman32-a-tool-to-generate-sxs-manifest-for-managed-assembly-for-registration-free-com-net-interop.aspx" rel="nofollow noreferrer">Manifest-Creator (very useful!)</a></li>
</ul>

blocks|key|395091|text|如果是我的话，我会直接把创可贴撕下。我看不出为您的应用程序提供介于.NET窗体和COM-interop之间的状态有什么好处，因为它只会增加不必要的复杂性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|395092|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|$]]

If it were me, I'd just rip the Band-Aid right off. I don’t see any benefit in having an in-between state [.NET Forms and COM-interop] for your application because it just adds unneeded complexity.

blocks|key|1751684|text|有很多关于转换策略的建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1751685|1751686|在这里查看其他问题，特别是如果你缺少开发人员的时候，强烈推荐Microsoft's+page关于商业迁移工具的不同转换。|unordered-list-item|offset|length|1751687|+(转换为c#和vb.net)|1751688|+(转换为vb.net))|1751689|和，我以前从未听说过，在编辑中建议使用(从vb.net)|1751690|1751691|转换为c#|1751692|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate^0|0|0|U|G|0|1|1|1|1|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@$F|11|G|12|1|13]]|A|$]]|$1|H|3|I|5|E|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|16|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

There's lots of advice on strategies for conversion.
<ul>
<li>Check out the other questions here tagged <a href="https://stackoverflow.com/questions/tagged/vb6-migration?sort=votes">vb6-migration</a>.</li>
<li>I highly recommend <a href="http://msdn.microsoft.com/en-gb/dd408373.aspx#migrate" rel="nofollow noreferrer">Microsoft's page</a> about different conversion strategies.</li>
<li>Consider the commercial migration tools especially if you are short of developer time.
<ul>
<li><a href="https://www.mobilize.net/solution/vb-upgrade-companion" rel="nofollow noreferrer">Mobilize.Net's upgrade companion</a> (converts to c# and vb.net)</li>
<li><a href="http://www.vbmigration.com/" rel="nofollow noreferrer">VBMigration partner</a> (converts to vb.net)</li>
<li>and <a href="https://phoenix.selise.ch/" rel="nofollow noreferrer">SELISE Phoenix</a>, which I haven't heard of before, suggested in an edit (converts to c# from vb.net)</li>
</ul>
</li>
</ul>

blocks|key|1143164|text|您描述的零敲碎打的方法将增加额外的工作，因为您将尝试让VB6和.Net代码共存，这在最简单的应用程序之外的任何情况下都充满了问题。在这条路上的某个地方，你可能会被一个陷阱绊倒，这可能是一个精彩的表演。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1143165|我推荐以下方法(基于成功地将一个600,000行的VB6应用程序迁移到.Net)：|1143166|确保您现有的VB6代码库得到了适当的版本控制和标签。为您的VB6代码库编写回归测试，最好是自动化的。将已知的VB6代码标记为baseline，并将其作为单个实体迁移到.Net。您的客户将继续使用VB6版本。在迁移后的代码上运行回归测试。当所有测试都通过时，将自采用原始VB6基线以来发生的任何VB6更改应用于.Net代码。送到UAT然后上线。|1143167|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 piecemeal approach you describe will create extra work because you will be trying to get VB6 and .Net code to co-exist, which is fraught with problems on anything but the simplest applications. Somewhere down the road you are likely to trip over a gotcha which may be a showstopper.

I would recommend the following approach (based on successfully migrating a 600,000 line VB6 app to .Net):

Make sure your existing VB6 code base is properly version controlled and labelled.
Write regression tests for your VB6 code base, preferably automated.
Take a known VB6 code label baseline and migrate it as a single entity to .Net. Your customers continue to use the VB6 version.
Run your regression tests on the migrated code. 
When all the tests pass, apply to the .Net code any VB6 changes that occurred since you took the original VB6 baseline.
Deliver to UAT and then live.

blocks|key|395461|text|如果您的系统在较长时间内同时使用一个、另一个或两个数据模型，您是否会一次转换一个大型复杂数据表？显然，这是在自找麻烦和复杂性。大型数据转换的最佳实践是在尽可能短的停机时间内将整个数据模型转换为所需的最终状态。同样的推理也适用于大规模的代码转换。在增加劳动力成本和技术风险方面，零散地重复和延长时间是自找麻烦。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|395462|更好的方法是为您的.NET代码制定最终状态开发和体系结构标准，然后投资于一个过程，帮助您以符合这些标准的方式高效地重写系统，并准确地保留遗留的业务规则和功能行为。长时间的过渡和复杂的混合/中间解决方案在最好的情况下只是一个权宜之计，在最坏的情况下会导致业务问题和项目失败--它们应该被避免。一种更好的方法将允许您将遗留软件以内部一致、独立和格式良好的片段形式交付到新平台。此外，以更少、更大的部分交付迁移将比许多小部分更有效率、更少干扰。|395463|使这种方法可行的关键是使用下一代VB6/COM/ASP+.NET工具，这些工具允许您迭代地校准、自定义和验证自动重写过程，从而平衡自动转换和手动工作。Great+Migrations的工具就是专门为支持这种方法而设计的。我们称之为“工具辅助重写”。我们已经在几个大型迁移项目中使用了这种方法，包括将VB6/COM的120万LOC的应用程序组合升级到重新设计的C#/.NET。|offset|length|395464|免责声明:我为Great+Migrations工作。|395465|entityMap|0|LINK|mutability|MUTABLE|url|http://www.greatmigrations.com/Services.htm^0|0|0|23|G|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Would you do a large complex data conversion one-table at a time, with your systems using one, the other, or both data models concurently for an extended period? Clearly this is asking for trouble and complexity. Best practice for large data conversions is to do them in a way that brings the entire data model to its desired end state within the shortest possible outage. The same reasoning applies to large-scale code conversions. Doing them piecemeal over and extended period of time is asking for trouble in terms of increases labor costs and technical risk.
IMO, a better approach is to formulate the end-state development and architecture standards for your .NET code and then invest in a process that helps you efficiently rewrite your system in a way that conforms to those standards and accurately preserves legacy business rules and functional behavior. Long transitions and complex hybrid/intermediate solutions are only a stop-gap at best cause business problems and project failure at worst -- they should be avoided. A better approach will allow you to deliver the legacy software to the new platform in internally consistent, independent, and well-formed pieces. Furthermore, delivering the migration in fewer, larger pieces will be more efficient and less disruptive than many little pieces.
The key to making this approach viable is to use next generation VB6/COM/ASP to .NET tools that allow you to iteratively calibrate, customize, and verify an automated rewrite process that balances automated conversion with manual work. The tools from <a href="http://www.greatmigrations.com/Services.htm" rel="nofollow noreferrer">Great Migrations</a> are specifically designed to enable this methodology. We call it the &quot;tool-assisted rewrite&quot;. We have used this approach on several large migrations projects including upgrading an application portfolio of 1.2M LOC of VB6/COM to re-engineered C#/.NET.
Disclaimer: I work for Great Migrations.

Would it be a good idea to start converting forms into .NET one at a time which you would then invoke from the VB6 app via COM-interop.

This way, by the end of the process you would just convert the 'shell' of the VB6 application into a new .NET app, and all your forms are ready to go in .NET.

Is there a better strategy?

Strategy for converting a VB6 app to .NET

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯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编辑器全新改版上线，欢迎大家体验!

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

社区新版编辑器体验调研

开始将表单一次转换成一个.NET，然后通过COM-interop从VB6应用程序调用它，这是不是一个好主意？这样，在该过程结束时，您只需将VB6应用程序的“外壳”转换为一个新的.NET应用程序，所有表单就可以在.NET中运行了。有没有更好的策略？

问将VB6应用程序转换为.NET的策略
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将VB6应用程序转换为.NET的策略EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将VB6应用程序转换为.NET的策略
EN