Before starting any migration from Visual Basic 6.0 to the .NET Framework (either VB.NET or C#), we always recommend that our clients perform at least a couple of pre-migration tasks that help streamline a potential migration process. Here is a brief summary of some of them:
- Code Cleanup: Sometime we run into applications that have modules that haven't been used in a while, and nobody really knows if they are still in use. Going through a Code Cleanup stage greatly helps reduce the amount of code that needs to be migrated, and avoids wasting effort in deprecated parts
- Code Advisor: It is also recommended that you execute Microsoft's Code Advisor for Visual Basic 6.0. This Visual Studio plug-in analyzes your VB6 code and points out programming patterns that present a challenge for the migration to .NET. Some of these patterns are automatically resolved by the VBUC, but even then, you should always use this rule of thumb: if you use high quality VB6 code as input for the VBUC, you get high-quality .NET code as output. Here is a brief example of the suggestion you'll get from the Code Advisor:
- Arrays that are not based on a zero index: Should be fixed in VB6
- Use of #If: Only the part that evaluates to "true" will be converted. This may cause problems after the conversion
- Use Option Explicit and Late binding, declare X with earlybound types: The VBUC is able to deduce the data types of most variables, but if you have an opportunity to fix this in VB6, you should take advantage of it
- Trim, UCase, Left, Right and Mid String functions: The VBUC is able to detect the data type being used and interpret the function (for example, Trim()), as a correct string function (in the example, Trim$()). It still recommended that you fix it before performing the migration.
There are other tasks that may be necessary depending on the project and client, like developing test cases, training the developers on the .NET Framework, preparing the environment, and countless other specific requirements. But if you are considering a .NET migration, you should at the very least take into consideration performing the tasks mentioned above.
One of the nicest features of the Visual Basic Upgrade Companion version 2.0 is the support for Migration Profiles. These profiles give you control over which translations to use for a particular migration, improving the quality of the generated code and applying only the conversions desired (for example, for specific third party components). Profiles are managed through the Profile Maintenance screen, as shown here:
If look at the screen in some detail, you will see some of the features included with the tool. Here you can select, for example, to convert the MAPI (Mail API) library to the Microsoft.Office.Interop.Outlook component. And it shows that this particular conversion has a coverage of 80%. This particular library shows why Migration Profiles are important. If the application you are migrating is an end-user application that is locally installed in the user's desktop inside your enterprise, and MS Outlook is part of your standard installation on these desktops, then it should save you quite a bit of work to let the VBUC perform this transformation. If, however, it is a server-side application where MS Office is very rarely installed, then having this option selected will only cause you additional work later on, as you will have to go through the code and remove the references.
Other good examples are the ADODB and ADOCOMMON plug-ins. Both of them convert code that uses ADO into ADO.NET. How they do it, however, is completely different. The first plug-in, ADODB, converts ADO into ADO.NET using the SqlClient libraries, so it only works with SQL Server. The ADOCOMMON plug-in, however, generates code that uses the interfaces introduced with version 2.0 of the .NET Framework in the System.Data.Common namespace. This allows the application to connect to any database using an ADO.NET data provider that complies with this interfaces - most major database vendors now have providers that meet that specification. So you can use either transformation depending on your target database!
The previous two examples illustrate the importance of Migration Profiles. As you can see in the screenshot above, the tool currently has a large amount of plug-in with specific transformations. This number is expected to grow over time. I will be covering some of these plug-ins in later posts. Stay tuned!
I was expecting the annoucement near the end of the week, but here it is - The Visual Basic Upgrade Companion version 2.0 was released today! Just in time to attend that other tool's funeral ;)
I am still waiting for the official press release, but at least the press here in Costa Rica is already talking about it (link in spanish). So you know, the VBUC2.0 is a considerable improvement over previous versions of the Companion. Some of the most interesting new features are:
-
Solves over 800 issues reported by our consulting staff, testing team, partners and end-users.
-
Significantly reduces the amount of manual work required to compile the migrated application, so you can start the testing earlier in the migration process
-
Improves the quality of the migrated code
-
Adds the concept of Migration Profiles - you can select from a series of migration features and apply only those that you want to a particular migration. This greatly improves both the quality of the migrated code, and decreases the amount of manual work required after the migration. It also allows greater future expandability of the product.
As you probably know, eye candy sells. And it makes your life easier, too. So the VBUC2.0 includes a new Graphical User Interface called the Upgrade Manager, that incorporates all the features and concepts described above into one easy to use environment:
If you have been thinking about upgrading your VB6 applications to the .NET framework, think no more. With this new version of the VBUC you will be able to have your .NET application up and running in no time!
I may be a little late to the obituary, but VB6 support is finally, officially, irrefutably gone. The IDE, as stated in Microsoft's Product Life-Cycle guidelines, "... will no longer be supported starting March 2008". Even though VB6 (or Basic for that matter) didn't enjoy the best reputation as a programming language (best illustrated by the famous Edsger W. Dijkstra quote), you can't deny the huge influence it's had over the past 15 years. The easy-to-use paradigm followed by VB IDEs lent itself to be used by both amateur programmers, that caused many headaches during the years, and professional developers that were really able to harness the power and ease of use to create impressively robust solutions that are still running to this day.
So if you are thinking of moving away form VB6, obviously I'm going to steer you in the direction of the Visual Basic Upgrade Companion. There is, however, another reason for this as well... pretty soon we are going to release a completely updated version 2.0 of the tool, which has some very interesting new features and does an incredible job of converting your VB6 code into the .NET language. Watch this space, as I will be writing about this new version soon!!
A quick post to let you all know that Beth Massi, Program Manager on the Visual Studio Community Team, will be doing a series of webcasts on Visual Basic 9. They will be mostly about the new features of VB9, including one about LINQ in VB that I am particularly interested in. Another one of them deals specifically with Visual Basic 6.0 to .NET migrations, called Live From Redmond: Migrating Your Visual Basic 6 Investments to .NET. If you haven't yet considered moving your VB6 application to the .NET Framework, this may be a good place to start. Remember that the end is near....
For more information on the webcasts, check out this post over at Beth's Blog.
In some migration projects you have to take an incremental approach. You just can't disappear with an application for a few months, and then come back with the application in the target language. Because of this, when we do migration projects, we try to divide the project in smaller milestones, so that developers can continue working on a certain module of the application, while another group migrates a different module.
It turns out that is you are migrating from Visual Basic 6.0 to the .NET Framework (using either Visual Basic.NET or C#), you can do even smaller steps. Microsoft offers the Microsoft Interop Forms Toolkit, a set of tools that you can use to run .NET forms and controls in VB6 applications. This Toolkit allows you to create an even less disruptive migration strategy, by creating an incremental upgrade process in which you can start out by moving some controls first, then some forms, and, before you know it, you'll have your applications running completely in .NET.
I realize this has been out for a while, but it is still worth mentioning, since there's tons of people out there that haven't moved from VB6 yet. This may give all of you some incentive to at least get started with the first incremental steps. :)
This tip isn't really migration-related, but I've used it so many times these past few days that I think it is worth sharing. We work with virtual machines A LOT, using Virtual Server 2005 R2 SP1. Every once in a while you need to log into a server using Terminal Services to delete old VHDs to make room for a new one, opr just for any other miscelaneous task that can't be done through the web administration client. And, unfortunately, sometimes there are two terminal services sessions open already, so you get the following error:
"Terminal server has exceeded maximum number of allowed connection"
You then stare at your monitor in frustration for a few seconds. After that, you figure out who the culprit is and ask him politely to "PLEASE LOG OFF".
Well, after discovering this tip, there is no longer a need to stare at your monitor or to ruin your relationship with your coworkers. Turns out there are a couple of command line tools you can use to close remote Terminal Services sessions. They are available in both Windows XP and 2003. The first one, qwinsta, lists all the open sessions on a particular server:
c:\>qwinsta /server:192.168.123.123
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
jpena 1 Disc rdpwd
administrator 3 Disc rdpwd
In this case, you can see that Juan Peña (user jpena) has an open session in the disconnected state. In order to close his session, you need to use the second tool, rwinsta:
rwinsta /server:12.12.12.12 3
This command will kill the session with ID 3 (jpena's). And voilà! After this, I'm able to connect to the server. :-)
Credit goes to Scott Forsyth's WebLog.
A quick post to tell everyone that the day finally came: Windows Server 2008 was released today. You can find more information about it on the Windows Server 2008 page, and watch the keynote here.
The biggest deal, from my perspective, is Hyper-V. This will have a significant impact on the IT market, by exposing thousands of IT profesionals to a hipervisor-based virtualization solution. Another very interesting technology is RemoteApp, which allows you to use, through Terminal Services, just one application instead of the complete desktop. It solves a deployment issue that required expensive software solutions in the past - and something we run into every once in a while when determining the best deployment strategy for migrated Informix 4GL applications.
Now that Visual Studio 2008 is available, you might wonder what will happen with the Visual Studio 2005 projects generated with the current version of the VB Upgrade Companion (VBUC). For starters, it is worth mentioning that Visual Studio 2008 fully supports projects created in the .NET Framework 2.0, like the ones generated with the VBUC. The newer version of the .NET Framework (3.0, shipped with Vista, and 3.5, shipped with VS2008) keep the same core version of the CLR (2.0) as before, with very few minor changes. There are no compatibility or breaking changes like when upgrading from versions 1.1 to 2.0 of the .NET Framework.
When you open a VS2005 project in VS2008, you are greeted with the new Visual Studio Conversion Wizard:
Once you click Next, you can select whether to create a backup of the project or not. I chose to NOT create a backup, since this is a copy of the project, since I will be comparing both .csproj files later on. Press Next.
The next step tells you what will happen during the conversion:
Press Finish, and after a little while, the process will be complete:
You can check out the Conversion Report afterwards. For most projects, however, the reports should be in blank:
So there you have it. After converting this test VS2005 Windows Form application, I was able to continue working on it without any issues. It is true that the code generated by the VBUC will not take advantage of all the neat features of the .NET Framework 3.5, such as WPF, but you should be able to continue working with the migrated code after moving to Visual Studio 2008 without any problems.
.... and so we reached 2008. This may seem like any other "average" year - the price of gas keeps going up, everybody talks about global warming, and will be an election year in the US (so we have one more reason to stop watching TV). However, for a large group of IT departments around the world, 2008 is a BIG year. 2008 is the year when Microsoft officially kills support for Visual Basic 6.0.
It took a while, but as in Chronicle of a Death Foretold, everybody knew it was coming. Microsoft's Product Family Life-Cycle Guidelines for Visual Basic 6.0 details the different support stages VB has gone through:
...
Mainstream Phase
The Mainstream phase will be in effect for six years after the product's general availability date. Visual Basic 6.0 was generally available in January 1999. Mainstream support will end March 31, 2005.
Extended Phase
The Extended phase will be in effect from seven to nine years after the product's general availability date. Extended Phase support begins in April 2005 and ends March 2008.
Non-Supported Phase
Visual Basic 6.0 will no longer be supported starting March 2008.
If you are still using Visual Basic 6.0, however, there is no need to despair. According to the Support Statement for Visual Basic 6.0 on Windows Vista, the VB6 runtime will be supported in Vista for at least 10 more years (5 of mainstream support + 5 of extended support). The IDE, however, will be unsupported from April 8, 2008. And you will be missing all the new technology shipping with the .NET development tools - web services, WPF, managed code, etc. There is, however, an easier way to move away from VB6 quickly...
You can use the Visual Basic Upgrade Companion to move your application quickly and effectively from VB6 to either Visual Basic .NET or C#. Our experience in migration projects shows that by using the VBUC, you can drastically reduce the time it takes to move your application to the .NET Framework, reducing the risk vs. a complete rewrite, and keeping all your business rules, but in a modern platform that will allow you to use the latest technologies moving forward.
You can find more information on the Visual Basic Upgrade Companion here.