Visual Basic 6.0 to VB.NET Upgrade Guidance – Community Pre-Release


The Patterns and Practices group is working on providing guildance on moving from VB 6.0 to either 2003 or 2005.  They are also working on a new Migration Assessment tool.  You can join the workspace for the upcoming guidance and get a preview of the guidance and upcoming Migration Assessment tool by checking out the community preview on their workspace.


Comments (5)

  1. Rufus T. Firefly says:

    RE: Converting VB6 to VB.NOT

    Your conversion tool is all backward. The trouble is lets say you take a 10,000 line application and try to convert it. Now you have 10,000 lines of code that not only doesn’t work, it won’t even compile, and it’s littered with "TODO" comments, and it’s written in a language that never should have been invented and nobody wants. But if someone wants to convert to VB.NOT, it would be better to proceed like this:

    Step 1. Run a tool that identifies conversion problems in the original code. Fix those problems while still in VB6 and while the app still compiles and works. I.e., without breaking the application you make it as convertable as possible.

    Step 2. Run the converter. Decide whether to continue on with the converted, broken code, or go back and continue to work on the original code.

    Here’s another problem with the converter: it should comment out unreferenced things that won’t convert instead of barfing. For example I have a huge .bas file full of declares for win32 calls. I share it between projects, but each project only uses a small percentage of the declares. So it would be a lot easier to convert if it didn’t barf on the stuff that isn’t even being used.

    Also: it would be nice if you would allow for user-defined conversion patterns. Then when something causes the converter to barf, on something that occurs all over the place in the program, I can add something to tell the converter how to handle it, rather than change every instance by hand. Also, something like a ‘HINT: comment in the original VB6 code might be a way to address some of these problems.

    I think you have grossly misunderstood the extent to which people have to work around Microsoft BS, so that you have things in VB code like a zillion API calls, memory copies, etc., stuff people had to do by experiment just to get the app to work the way they wanted.

    Well, you have my sympathy. VB.NOT was a HUGE mistake, and now you’re stuck. I can’t believe, no, I CAN believe, Microsoft took the most successful program language of all time, the one product Microsoft was ever competent to develop, and trashed it. Cool!

    Thanks and keep up the good work!

    Sincerely,

    Ruf

  2. Brad_McCabe says:

    When we talk with people at migration we talk about various approaches and picking the option that works best for you. It is not all about some magical wizard that is a 100% percent perfect for every person and every situation. Each application and company is different and needs to be examined for the best solution.

    For some folks using COM Interop and having VB 6 and VB.NET in the same application is the best option. For more information on this see http://msdn.microsoft.com/vbrun/vbfusion/default.aspx or http://msdn.microsoft.com/vbrun/staythepath/additionalresources/upgradingvb6/chapter9.pdf. This is the course of action most people take. You can leave middleware allow in COM objects and replace the front end. You can replace the middleware and leave the front end allow, the possibilities are pretty open to migrate in steps of months or potentially years if desired.

    For some people the state of the application, age, quality of the original application, in house knowledge of the code, etc… can lead to the recommendation that the best course of action is to rebuild the project from scratch. While the most work, in some cases, this is the best and fastest approach.

    For some people migrating 100% of the code at once is the best option. When this is the case our recommendation is exactly the two steps that you suggest. First we recommend that you use the Add-in Code Advisor in VB 6.0 to help clean up any issues ahead of the migration.

    For more information on the Code Advisor visit http://msdn.microsoft.com/vbasic/downloads/codeadvisor/default.aspx..

    The description from the page is “The Visual Basic 6.0 Code Advisor is a new add-in that can assist developers in making a successful transition to Visual Basic .NET. Once installed, the add-in can scan your Visual Basic 6.0 projects to ensure they meet predetermined coding standards. The Code Advisor can also suggest changes and best practices to ease your migration from Visual Basic 6.0 to Visual Basic .NET, and enables you to create custom scanning rules to check your Visual Basic 6.0 code for compliance with your own personal or development team best practices. “

    This covers many of the points you raise. It raises issues in the VB 6.0. You can and should fix the problems in the VB 6.0 code and recompile and run it.

    Then we suggest that you run the application through the migration wizard, your step two.

    This will migrate your code to VB.NET. The success of this depends on many factors. If you did not run the Code Advisor or follow it’s guidance you will have a much lower degree of success, but for most people this converts anywhere from 60% (for those that did not follow VB 6.0 best practices or listen to the code advisor) to 90% of their code without issue. The exact percentage depends on many different factors, if you have a simple application you might even hit 100% but let’s call the top end 90%. (Disclaimer – these are not from some offical study but rather my experances talking with developers) For argument’s sack we’ll pick around the middle and say you fall into the 80% range.

    That means that 80% of your code is perfectly fine. The other 20% has some issue you need to address. Here this numbers is a bit misleading. While you could have hundreds of TODOs in your code (for a large project) you will find that often there is a limited number of distinct issues. More often then not it is the some problem or code issue that is repeated over and over in your code. Once you correct the problem it is a matter of cut and pasting the solution 20 or 50 times over and over. While cutting and pasting can be boring it is much faster then fixing 50 unique bugs. Your suggestion for a “hint” ability is a valid suggestion and the first time I have personally heard that.

    When you migrate the code to VB.NET your VB 6.0 project files are left untouched. This means you have the option of addressing any issues in the VB.NET code, walking away from the migration, or running both code bases together. All of the options you suggest we should give you.

    When it comes to unused variables and declarations we take the approach that you are the developer and you put it in there for a reason, we are not going to just comment it out because it is used at the moment. You see something similar to this in VB 2005. For the first time we raise a compiler warning if you declare a variable but never use it. This is not a compiler error, so you can still compile and run. We simply flag it so you know that it is done.

    In your example of Win32 API calls in a shared file why would you not want to fix them all in the file the first time that way when you converted the other projects that you the other declarations that work is already done?

    I won’t get into a debate around “no body wants it” other then to say we have numerous case studies online from various companies, traffic is good and increasing on the VB web sites, and a large percent of VB 6.0 developers have migrated forward and embrace the productivity enhancements and features of VB.NET and VB 2005.

  3. SiGiD says:
    • I certainly side with the VB.NOT side, as VB.NET is "NOT" VB, in the sense that VB1 thru VB6 was VB. VB.NET is merely C# with a few VB constructs (similar enough to be confusing) thrown in as an afterthought.

      – If I should decide to program for .NET (which I might, after it stabilizes; I refuse to shoot at a moving target!) I will use the language for which .NET was clearly designed – C#.