VB6 application migration

Migrating a VB6 application to the .NET platform is almost like rewriting, whether it is VB.NET or C #. Do you think this will require more effort for this on the Java platform than on the .NET platform, since in any case this is a rewrite? Share your thoughts!

+4
source share
8 answers

Do not be offended, but you are mistaken. Porting to .Net is usually far simpler than rewriting.

Here is the official Microsoft UK tip:

Performing a complete rewrite in .NET is much more costly and complicated to succeed [than converting] ... we would recommend this approach only for a small number of situations.

From a blog post from a Microsoft guy who consulted about rewriting:

Many of the companies I worked with in the early days of .NET first looked at rewriting, partly due to a strong desire to improve the underlying architecture and code structures while switching to .NET. Unfortunately, many of these projects encountered difficulties, and some of them were never completed. The problem they were trying to solve was too big

I recommend that you complete the following two steps in this order.

  • Record the reasons for migration or rewriting. What benefits will it bring? The benefits can only be that the development team is happy - this may even be a good enough reason, I don’t know. Make sure you know and your managers / users agree.
  • Check out Microsoft's recommendation with a screencast explanation of 5 basic migration options. Net. Decide which one is better. It may be a rewrite, but enter it with your eyes open.

In response to your real question: will a complete rewrite be easier in .Net or Java? It basically depends on which your team knows best. It also slightly depends on whether the application interacts with COM, as SLaks says.

+8
source

The effort to rewrite the VB6 application is not just a matter of what language you are targeting. VB applications often rely on COM objects and certain VB-specific library methods, which may not have equivalents in Java - but may have some portability in .NET.

If you do not want to abandon all the project dependencies, you may find .NET an easier target for re-writing, especially if you need to preserve some of the behavior of an existing application that comes from libraries or other dependencies.

Another consideration is which platform your team is most familiar with - if you have a lot of Java experience but little or no .NET experience, then maybe Java is a good choice for you.

+2
source

Tools are available that will migrate from VB6 to VB.Net, including the built-in Visual Studio. This tool port VB6 to C #. No matter which tool you use, you still have to do most of the manual work on the code that the tool outputs, however it will probably be less than a complete java rework.

Depending on the existing architecture of the application and how well structured the code is, you may decide that it is better to completely reverse engineer and rewrite it anyway, in which case there may not be much choice between .Net and java.

+1
source

It is important to reduce not only the overall efforts during migration, but also the costs of maintenance after migration. Many factors influence TCO, but all things being equal, I believe that the .NET tools, community, environment, and C # language meet or surpass Java in terms of productivity, operational manageability, and developer productivity, assuming that you focus on Windows .

I do not believe that the ease of saving COM should also be a decisive factor. Actually, I think that porting VB6 to .NET, but saving COM when you don't need to defeat the critical mission of VB6 migration in the first place: reduce development costs and risks by switching to a well-supported and viable platform. I will tell you why:

  • Most of the popular COM libraries and controls that were used with VB6 have not been developed for many years; many of the smaller vendors have disappeared or if they still support their products, now they also offer new and improved versions of .NET.

  • Living with the old COM after migration means living with additional complexity in terms of debugging, assembly, and deployment. Also be careful that COM components do not actually say β€œ.NET”. (i.e. they don’t use .NET types and conventions), so using them with .NET usually leads to additional coding and design complexity.

  • There are a few excerpts and exceptions to this rule and .NET replacement is not always the best choice, but in general, migration groups will be able to find at least one .NET replacement option for almost every COM component that they use. Taking the time to thoughtfully evaluate, choose and update to one of these options will pay off after the migration.

  • You will not want to interfere with anything, this is the VB6 that you plan to transfer. Interaction of your own code will lead to a longer, more complex transition and, as a rule, requires reverse tracking and recycling / re-verification of codes that have already been transferred. Clearly, this is not the most effective and understandable update track.

Another point related to the need for "a lot of manual work on the way out." Great Migrations is a new, programmable migration tool. It is designed to help migration teams gradually improve the quality of the generated code and thereby reduce the manual work required to complete the migration project. This includes correct translation, handling complex migrations with multiple VBPs, and automating the restructuring of VB6 / COM code to use .NET components. These functions are especially useful if the VB6 code base is very large, often changes, and is significantly reconstructed and cleared during migration. This is a flexible migration methodology that we call tool reinstallation.

Disclaimer: I work for Great Migrations.

+1
source

If an application uses COM, it will be much easier to rewrite it in .Net than in Java. Otherwise, it might be a little easier to port to .Net.

For a more specific answer, please provide more information about your application.

0
source

You can also use Jabaco, this is the Java Bytecode compiler, and it has its own IDE and syntax very similar to VB6 (almost the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/

0
source

use a migration tool like ArtInSoft to just port it to .NET.

0
source

You can port your VB 6 application using the built-in migration of VS to VB.Net. Try to see if this helps you. If you are looking at porting VB 6 to C #, I also recommend that the user recommended by ScaleOvenStove.

0
source

Source: https://habr.com/ru/post/1309441/


All Articles