Because of some queries we’ve had in the past few days, I think it is time to revisit the differences between the Upgrade Wizard that ships with Visual Studio .NET (2003,2005 & 2008) and the Visual Basic Upgrade Companion (VBUC). The VBUC is a different product, with very different capabilities than the Upgrade Wizard. We have a detailed comparison over at the Visual Basic Upgrade Companion vs. Upgrade Wizard page, but here is a brief overview of the main differences:
- C# Generation: The Visual Basic Upgrade Companion is able to generate C# directly from the Visual Basic 6.0 source code, as an alternative to Visual Basic .NET.
- Structured Error Handling: The Visual Basic Upgrade Companion includes features to remove unstructured “spaghetti” code and replace it with structured flow control statements in .NET. All unused labels are removed from the resulting code. Plus the most commonly used “On Error ” patterns are currently recognized and replaced by the tool. This is important for C# migrations, as it ONLY supports structured error handling.
- .NET Native Libraries: Instead of upgrading VB6 code using the Visual Basic Compatibility Libraries like the Upgrade Wizard does, the Visual Basic Upgrade Companion promotes the use of .NET native libraries whenever possible.
- Type Inference: The VBUC contains a typing system that accurately assigns correct .NET data types to existing VB6 variables, functions, fields, parameters, etc
- Stub generation: To ease the compilation process, the Visual Basic Upgrade Companion generates an empty declaration (stub) in a stub-dedicated source code file and into the converted project for each library element which occurs in the original application and does not have an equivalent in .NET. All the references to these not-converted elements are translated into references to their corresponding stub declarations. This strategy does not fully resolve the lack of .NET equivalent elements, since the stubs will require manual implementation, but, it saves an important amount of time during the manual changes stage.
- Code quality enhancements: The VBUC generates higher quality code with more mature and exact transformations. These transformations include data type enhancements and grammar pattern transformations and detailed code improvements. A detailed explanation of these transformations can be found on the VBUC vs. UW page.
- Multi-Project Conversion: The Upgrade Wizard is able to convert one single VB6 project file (*.vbp) at a time. Hence, if the user wants to upgrade a complex VB6 application with this tool, several considerations must be taken in order to accomplish full functional equivalence. The Visual Basic Upgrade Companion allows the conversion of multiple Visual Basic 6.0 projects. It performs a separation between the pre-processing and migration stages in order to fix problems like the use of by-ref parameters, interfaces, renaming and typing among the different projects. The pre-processor environment solves the references among projects and simplifies the overall migration process.
- .NET Enumerations: Another important Visual Basic Upgrade Companion feature, absent in the Upgrade Wizard, is the replacement of numeric literals assigned to several control properties with .NET enumeration equivalents when possible, so that the generated Visual Basic .NET code is more legible and maintainable.
- 3rd Party Library Extensibility*: The VBUC can be customized to convert any third party library to its native .NET equivalent. It ships with support for several libraries out of the box, which are detailed in the VBUC vs. VBUW document.
- Legacy Data Access to NET*: The VBUC upgrades the legacy data access models (ADO, RDO, DAO, ADOR) to .NET equivalents, employing special transformation rules and helper classes (for some specific source/target combinations). On the other hand, the UW generates a target application that still uses those legacy data access models to communicate with the database via COM Interop wrapper calls.
- Custom Maps*: The Visual Basic Upgrade Companion Custom Maps extensibility, allows the user to upgrade their non-supported libraries and controls using a simple set of user-defined transformations.
- User declarations advanced refactoring*: The Visual Basic Upgrade Companion manages all the user declarations to perform tasks such
as using standard Naming Conventions for the .NET languages and recognizing conflictive user-declaration names to assign new denominations (including all of its references).These tasks improve the resulting source code readability and hasten the manual change stage.
- COM class exposure*: When this optional feature is enabled, the Visual Basic Upgrade Companion will generate attributes for the COM-exposed classes and their members, in order to keep the resulting assemblies exposed through a COM interface. This enables the resulting components to be called from other non-managed components via COM.
Make sure you download the PDF on the Visual Basic Upgrade Companion vs. Upgrade Wizard page for additional details. Items marked with * are ONLY available in the Visual Basic Upgrade Companion (VBUC), and are not available in the VBUC Developer Edition.
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.
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.
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.
Planning and performing a Visual Basic 6.0 migration is not that straightforward. You need to keep track of many small details, and you need to keep in mind the complete migration process – in other words, always see the big picture. The tool I posted about yesterday, the Code Advisor and the Assessment Tool, are invaluable in the help that they provide during the planning stages of the project. For the complete upgrade process, however I have to recommend the Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005 guide from the patterns & practices Developer Center over at MSDN.
This guide was written as a joint effort between Microsoft and ArtinSoft, and details all the steps necessary to succesfully upgrade your applications to Visual Basic .NET. It also deals with the actual technical hurdles you normally face when performing these types of conversions. Overall it is very comprehensive, and should be in your library if you ar planning or performing one of these projects.
If you are using the VB Upgrade Companion, and decide to upgrade to C# instead, most information from the guide still applies. That is one of the beauties of the .NET Framework – the concepts from VB.NET work with C# as well.
Yesterday I blogged about the Code Advisor, that will pinpoint common programming practices that difficult the migration of a VB6 application. Well, another very important tool that you can add to your arsenal is the Visual Basic 6.0 Upgrade Assessment Tool. This tool was developed by ArtinSoft, and creates a spreadsheet with detailed information of actual upgrade issues that will be present in the .NET code after the migration.
This tool is also a free download from Microsoft’s website. You can also check out ArtinSoft Visual Basic to .NET page for more information on upgrading Visual Basic 6.0 applications.
If you are considering to upgrade your Visual Basic 6.0 application to Visual Basic .NET or C#, remember that the recommended first step is to run Microsoft’s Code Advisor. The Code Advisor, according to the website:
The Code Advisor for Visual Basic 6 is an add-in used to review your code to ensure that it meets predetermined coding standards. The coding standards are based on best practices developed by Microsoft to produce robust and easy-to-maintain code.
The Code Advisor detects issues that are not converted automatically during the automatic migration, increasing the manual work required after running the conversion tools. These include Variant variables, late binding, soft binding of different objects, and others.
Check it out: Code Advisor for Visual Basic 6.0
The Visual Basic Upgrade Companion allows you to convert calls to the Win32 API from Visual Basic 6 to C#. API calls in VB6 have the following syntax:
Public Declare Function RegOpenKey Lib "advapi32.dll" _
Alias "RegOpenKeyA" (ByVal hKey As Long, _
ByVal lpSubKey As String, phkResult As Long) As Long
The equivalent API call in C#, using platform invocation (p/invoke) is:
[DllImport("advapi32.dll">)]
extern public static int RegOpenKey(
IntPtr hKey, string lpSubKey, out IntPtr phkResult);
Even though the upgrade companion performs the conversion automatically, there are times when the protoype of the function may be slightly off. This happens mostly because of the changes in the data types between VB6 and C#. One example is when a string is sent to a method and its contents are modified in the call. String management is always tricky, and, in those cases, chances are that the VB Upgrade Companion will convert the VB6 fixed length string to a System.String object in C#. The correct conversion would be a System.StringBuilder object – remember that Strings are inmutable in C#, but StringBuilders are not, and they can be marshalled to the API as the strings that need to be modified.
If you ever have a doubt regarding the prototype of a Win32 API function in C#, I recommend that you check out PINVOKE.NET. This website contains the P/Invoke signatures for most methods of the API, classified by DLL. It is very complete, and can definitely save you lots of time if you are having problems with a particular methods.
If you are new to p/invoke, I also recommend that you check out this MSDN article on the subject.
One of the best features of the Visual Basic Upgrade Companion, Enterprise Edition, is the fact that it transforms your ADO code into ADO.NET. The Companion converts most of ADO features automatically, and it work correctly even if you choose to generate C# code.
One detail, though, is that the generated code by default uses the SQL Client for ADO.NET connections. This brings huge performance increases to the application, but we’ve run in to the situation in the past where the original datasource was not SQL Server. We’ve seen applications that used the Jet Database Engine, which is no longer supported by the latest version of MDAC, and is definitely not supported by ADO.NET’s SQL Client.
The solution for these scenarios is to use the Microsoft Access Upsizing Wizard. So far we haven’t seen any issues when upsizing the data, but there are other features that are not supported by the wizard. Once you upsize your database into a SQL Server installation (it even works with SQL Server 2005 Express Edition – which is great news for smaller installations), the final step in your application is to update the connection string used. The easiest way to get a hold of the new connection string is to create the connection inside Visual Studio 2005, and then copy the Connection String from the connection’s properties:
It is also important to mention that this and most other behaviors can be customized through our consulting services. We can also carry out the complete migration process as well.