Visual Basic 7, also known as VB.NET, was released in 2002. At that time a significant number of compatibility issues were identified. Many of those issues were not changes to the core language but rather missing libraries.
For example, at the time it was impossible to convert any VB application that had printing capabilities. Though the VB6 Printer object was quite primitive, and the PrintForm command downright trivial, neither were included in VB.NET. Even the line and shape controls, which are essentially a couple of properties and an OnPaint event, were missing.
It is now 2007 and Microsoft has finally released a Visual Basic 2005 PowerPack that includes these features. What's troubling is that there is no mention of including this in VB 9 or the .NET 3.5 framework. Nor is there any mention of integrating this into the VB6 to VB.NET migration wizard.
With practically all support for VB 6 in the process of being ended, it is imperative that applications be migrated to a platform with long-term viability. But with Microsoft only giving lip service to the migration path, the future looks bleak for the countless companies running on VB6 applications.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/dotnet-spa-templates-proxy/en/smallimage/ASP-NET-SPA-templates-proxy-changes-small-1683016303172.jpg)
/presentations/net-apps-cloud/en/smallimage/infoq-live-logo-small-1683100880551.jpg){kind=logo}
/articles/asp-dotnet-minimal-apis/en/smallimage/logo-1678972581766.jpg){kind=logo}
/articles/functional-dotnet-development/en/smallimage/Fsharp-vs-Csharp-is-one-more-functional-than-the-other-small-1676023056578.jpg)
/articles/dotnet-grpc-json-transcoding/en/smallimage/logo-1674822319367.jpg){kind=logo}
/articles/Dotnet-Seven-MSMQ-Alternatives/en/smallimage/logo-1670585778128.jpg){kind=logo}
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
Community comments
different oppinion
by Frank Zehlius,
Re: different oppinion
by Jonathan Allen,
Re: different oppinion
by George Jiang,
Its called a "Tool-Assisted Rewrite"
by mark juras,
different oppinion
by Frank Zehlius,
Your message is awaiting moderation. Thank you for participating in the discussion.
I personally think that these libs shouldn't even be there.
.NET is so different from VB6 that there is no way anything acceptable will come out of such a process.
As a freelancer i have done "migration" to .NET since 2001 and I can tell you that
it is a lot easier to rewrite everything than to try to migrate.
Nearly nothing is done in a similar way in .NET than it was done in VB6.
And if you stay in the mindset of a vb6 developer than you will miss the whole new world.
Re: different oppinion
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I agree with you in spirit, there are a lot of companies that simply cannot afford a complete rewrite. The ability to port everthing and then upgrade the code at a slower pace is the only way they can handle the situation, other than remaining on VB6.
Re: different oppinion
by George Jiang,
Your message is awaiting moderation. Thank you for participating in the discussion.
How can you "upgrade" those .NET code converted from VB6 by tools (aka machine generated code)? Re-write.
It is re-write at once or re-write gradually. But if you cannot afford to re-write at once and want to re-write gradually, why would you convert? For maintemance? Will it be easier to maintain the original VB6 code than maintaining the generated VB.NET code from VB6?
Its called a "Tool-Assisted Rewrite"
by mark juras,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is so true: .NET and VB6 are different -- languages, tools, frameworks, you name it. A direct 100% conversion is not even feasible let alone desirable. Major of redesign is required and alot more is desired. Failure to do the redesign will end up costing you more in terms of higher TCO after the migration.
It is also true that rewriting large applications "from scratch" is not feasible: big, mature apps contains many 1000s of detailed business rules and functional requirements. All these requirements were painstakingly gathered, validated and implemented over 10s or even 100s of person-years of work by cross functional teams of developers and business people working together to define and refine the behavior of the systems. Attempting to redo all of this work "from scratch" is extremely disruptive and risky and will blow the total cost of conversion (TCC) out of the water.
The good news is that the As-Is business requirements and myriad technical details are specified accurately and completely by the legacy source code. You can leverage that vast resource if you have a tool that correctly parses and interprets large VB6/COM codes (i.e., a compiler). But rather than a traditional compiler, you need one that decompiles/authors the system in the target language. The products from www.greatmigrations.com do this.
Of course a tool cannot predict designs that are "right" for all situations, so the flexibility of the tool is critical. Convert or rewrite, by tool or by hand, you will have to learn .NET and formulate/test appropriate new designs and standards. You will also have to upgrade your skills and your processes so you are ready to build, deploy, and maintain a large system on .NET. That is going to be expensive too. Even more the reason to leverage tools that reduce the costs of requirements gathering, coding, and testing so you can allocate more resources to training, design, and retooling where it is really needed.
The way to minimize TCC during the migration and control TCO after the migration is to use tools that help re-implement the existing source code in a way that conforms to a new design that is appropriate for and takes advantage of .NET. The process is much more agile and manageable than starting over.