Migation of a VB6 application to .NET platform is almost like a rewrite, no matter it is VB.NET or C#. Do you think it will require more effort to do it in Java platform, when compared to .NET platform, since it is a rewrite anyway? Please share your thoughts!
A:
If the application uses COM, it will be far easier to rewrite it in .Net than in Java. Otherwise, it will probably be somewhat easier to port to .Net.
For a more specific answer, please provide more details about your application.
SLaks
2010-05-11 16:00:15
+2
A:
The effort of rewriting a VB6 app is more than just a question of which language you're targetting. VB apps 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.
Unless you are willing to abandon all of the dependences of the project, you may find .NET an easier target to re-write for, especially if you need to preserve some of the behavior of the existing application which derives from libraries or other dependencies.
Another consideration will be which platform your team is most familiar with - if you have a lot of Java expertise but little or no .NET expertise, then perhaps Java is a good choice for you.
LBushkin
2010-05-11 16:01:53
Good point about COM dependency, thanks!
WinFXGuy
2010-05-12 20:53:20
I think the issue is much less about COM per se than a question of whether equivalent components exist in another framework. COM is just the component technology, and usually the functions of the pre-packaged code glued together by the VB6 code is a bigger issue. Stop thinking of components as "dependecies." That's a bit like calling a car's engine a "dependency."
Bob Riemersma
2010-05-13 00:51:43
@Bob I think that's what LBushkin means: whether the methods/components have equivalents in Java i.e. it's about the functionality. Just BTW - have you ever actually replaced a car engine with a different type of engine? Say petrol->electric or petrol->diesel? Certainly possible but fairly expensive I suspect.
MarkJ
2010-05-14 12:13:36
@Bob Reimersma: There's really two issues that have to be addressed - the first is what (if any) COM components exist that the code is dependent on, and what those components do. Regardless of the technology, software components are rarely 100% interchangeable, and may result in different end-user behavior if one is swapped for another. Part of such a porting/rewrite effort would be to identify what the end behavior of the system would be if a different platform is chosen.
LBushkin
2010-05-14 13:15:26
Bob Riemersma
2010-05-15 04:35:15
+1
A:
There are tools available that will migrate from VB6 to VB .Net, including the one built into Visual Studio. This tool migrates VB6 to C#. Whatever tool you use, you will still need to do a lot of manual work on the code that the tool outputs, however this is likely to be less work than a complete java rewrite.
Depending on your existing application's architecture, and how well the code is structured, you may decide it is better to completely re-design and rewrite it anyway, in which case there may not be much to choose between .Net and java.
ShellShock
2010-05-11 16:03:49
That tool sounds rather weak. Check out Artinsoft.com or VBMigration.com who have the leading migration tools as far as I know. They both claim a minimum of manual work on the migrated code and certainly far less than a rewrite. Oh, and be cautious about rewrites. http://stackoverflow.com/questions/2812224/migration-of-a-vb6-application/2815414#2815414
MarkJ
2010-05-12 00:46:25
I have used both the Netcoole tool, and Artinsoft. I agree that Netcoole is quite weak, but it is very cheap! You will have to do a lot of manual work on the output. As well as the tool, Artinsoft offer an excellent migration service--much more expensive, but you do not have to do any migration work yourself. Artinsoft also wrote the upgrade wizard supplied in Visual Studio, which is a cut down version of their main tool.
ShellShock
2010-05-12 08:15:14
But, if the applications uses a lot of third party COM objects, it might be better to stick with .NET
WinFXGuy
2010-05-12 21:00:42
+3
A:
No offence, but you are wrong. Porting to .Net is usually far easier than a rewrite.
Here's the official advice from Microsoft UK:
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.
From a blog post by a Microsoft guy who consulted on rewrites:
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
I recommend the following two steps in this order.
- Write down the reasons for migration or rewriting. What benefits will it bring? The benefits might be just to keep the development team happy - that might even be a good enough reason, I don't know. Make sure you know, and your managers/users agree.
- Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. It may be rewriting, but go into it with your eyes open.
In answer to your actualy question: would a complete rewrite be easier in .Net or Java? That mainly depends on which one your team knows best. It also depends a little on whether the application interacts with COM, just like SLaks says.
MarkJ
2010-05-12 00:42:29
@BhejaFry Thanks, put up the logo a while back, I'm glad it's been appreciated at last!
MarkJ
2010-05-12 00:55:49
Thanks MarkJ. The reason for the complete rewrite mentioned in the above link you posted are perfectly valid for our situation. But as a .NET consultant, I need to convince the Manager, that it is better to port it to .NET platform, rather than Java platform. He has some in house Java developers, so he thinks he can save money. I still need to see the existing VB6 code, to evaluate the COM dependency of this application. But, you do have good points, just like others said about COM dependency.
WinFXGuy
2010-05-12 20:50:13
@WinFXGuy Presumably this organisation actually **pays** its in-house Java developers - their workhours aren't free. Tell the manager it would likely need many more developer hours to rewrite in Java than it would to port to .NET, i.e. it's likely to work out cheaper. He needs to decide how much extra he wants to pay to get a Java app rather than .Net. Above all else he needs to decide exactly why he's commissioning a port/rewrite. What are the benefits to the business?
MarkJ
2010-05-14 12:02:53
A:
You could also use Jabaco it is a Java Bytecode compiler and it has it's own IDE and syntax very similar to VB6 (nearly the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/
Oops
2010-05-12 09:09:37
A:
use a migration tool, like ArtInSoft to just migrate it to .NET.
ScaleOvenStove
2010-05-12 20:56:35
A:
You can migrate the VB 6 application using the in built VS migration to VB.Net. Try to see if that helps you. If you are looking at migrating VB 6 to C# then I would also recommend what ScaleOvenStove user has recommended.
KZoal
2010-05-13 01:41:54
A:
It is important to reduce not just the total effort during migration but also the cost of maintenance after migration. Many factors drive TCO, but all things being equal I think the .NET tools, community, framework, and C# language meet or beat Java in terms of developer productivity, operational managability, and performance -- assuming your are targeting windows OS.
I do not think ease of keeping COM should be the deciding factor either. In fact, I think migrating VB6 to .NET but keeping COM when you do not have to defeats a critical purpose of doing a VB6 migration in the first place: to reduce development costs and risks by moving 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 evolved in many years; many of the smaller vendors have disappeared or if they are still supporting their wares, they now also offer new and improved .NET versions.
Living with old COM after migration means living with additional complexity in terms of debugging, builds, and deployment. Also beware that COM components do not really "speak" .NET (i.e they do not use .NET types and conventions) so their use with .NET usually results in added complexity in the coding and design.
There still are a few hold-outs and exceptions to this rule and a .NET replacement is not the always best choice, but in general, migration teams will be able to find at least one .NET replacement option for almost every COM component they use. Taking the time to thoughtfully evaluate, select and upgrade to one of those options will pay off after the migration.
You will not want to interop anything that is VB6 you plan to migrate. Interoping your own code will lead to a longer, complex transition and typically requires back-tracking and reworking/retesting already migrated codes. Clearly this is not the most efficient and understandable upgrade path.
One more point about having to do "a lot of manual work on the output". The Great Migrations product is a new, programmable migration tool. It is designed to help migration teams incrementally improve the quality of generated code and thus reduce the manual work required to complete the migration project. This includes making the translations more correct, dealing with complex multi-VBP migrations, and also automating the restructuring of VB6/COM code to use .NET components. These features are particularly helpful if the VB6 codebase is very large, changing frequently, and being significantly re-engineered and cleaned up during the migration. This is an agile migration methodology we call the tool-assisted rewrite.
Disclaimer: I work for Great Migrations.
mark
2010-05-13 02:35:20