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.
One of the key features of the Visual Basic Upgrade Companion (one that is not present in the Developer Edition, BTW) is that it’s functionality can be customized and extended. By doing this, developers working on a migration can have the VBUC do as much of the work as possible for them, minimizing the manual work and producing a higher quality product that satisfy both the developer’s and end user’s expectations. Performing repetitive changes to, for example, replace the data access components from VB6 (ADO/RDO/DAO) with native .NET data access (ADO.NET), is better done by the VBUC at migration time. This also applies to particular programming patterns used by organizations that need to be replaced by .NET-native patterns, and to coding conventions that vary between VB6 and .NET languages.
The Visual Basic Upgrade Companion includes three mechanisms to customize the generated code: Migration Profiles, Custom Maps and Additional Customizations.
Migration Profiles
A new feature that was introduced in version 2.0 of the Visual Basic Upgrade Companion, it gives end users control over which features and transformations to use for a particular migration, by using the concept of Migration Profiles. These profiles provide two types of rules that can be switched on/off. The first type, Code Conversion Rules, that deal with patterns applied to the code, such as generating structure error handling (try…catch) from On Error…Goto statements or applying commonly used naming conventions to the code. The second type is called Component Maps, and deal with translations from from one ActiveX component, such as a status bar or a grid, to a native version of the component.
Profiles are managed through the Profile Maintenance screen:
Custom Maps
The Visual Basic Upgrade Companion includes a “mapping” mechanism that allow end-users of the tool to define the transformation of one element of a library used in the VB6 code to a member of an assembly in .NET. This allows a migration team to identify and implement time-saving transformations, and, when combined with the implementation of an adapter for the .NET component, can speed up the migration process dramatically.
The Mappings are defined through a GUI editor launched from within the VBUC itself:
Once the mappings are defined, they can be switched on and off in the migration through the Migration Profile Maintenance Window:
Additional Customizations
ArtinSoft’s VBUC development team can also include additional complex rules in the VBUC, including customizations for items such as error handling patterns, architectural modifications, and others. These customizations also include mapping COM controls to in-house libraries, or force in-house naming conventions. This was a decision point for one of clients in the United Kingdom, Vertex Financial Services, as documented in the Vertex Omiga case study:
“Vertex decided to migrate the Omiga application to C# using a customized version of the Visual Basic Upgrade Companion, a tool developed by ArtinSoft based on artificial intelligence technology. ArtinSoft was highly recommended by Microsoft UK, and the customization of this migration tool enabled Vertex to automatically convert coding patterns and meet its preferred standards.”
These type of customizations require some modifications to the VBUC that can only be performed by ArtinSoft’s in-house team. It is a very valuable option that allows companies to get a an end product which furthers increases the return on investment from the migration.
Earlier this week we launched an joint initiative with Microsoft and Avanade in the UK for helping Visual Basic 6.0 developers move their applications to .NET. The initiative consists of several parts:
The initiative is UK-only at the time, but if you want to take advantage of these time-limited deals feel free to contact us. The press release for the campaign can be found here and at our website. Eric Nelson from Microsoft has been heavily involved - you can read his blog post on the initiative here.
The campaign has been well received so far. In the two days since launch, we already have several leads interested in both offerings!!
Jointly with the Visual Basic 6.0 migration campaign we are launching in the UK, today we released the Visual Basic Upgrade Companion Developer Edition. This is a scaled down version of the Visual Basic Upgrade Companion, targeted at individual developers that want to migrate their Visual Basic 6.0 applications as fast and painlessly as possible. It has a license that is valid for three months and allows you to migrate an application of up to 50,000 lines of code.
The VBUC Developer Edition does have some fewer features than the fully-fledged Visual Basic Upgrade Companion. All the features that we decided to include in the Developer Edition, however, are targeted towards automating as much of the migration process as possible. So, we left out features that have been introduced by the request of our enterprise customers over the 7+ years the tool has been on the market (yep, we were already doing VB6 migrations before the official release of .NET - and it wasn't all fun with the Betas). We made it so that getting an application up and running in C# or VB.NET is as simple as possible.
Here you can see the VBUC Developer Edition in action (video recorded by yours truly :) ):
And, as an introductory offer, The VBUC Developer Edition will only cost £199 for a limited time. So why wait?
Microsoft's Patterns & Practices group released last week a new version of the Application Architecture Guide. This book provides you with the best practices in the design of .NET applications. I recommend you read this when planning the evolution of your migrated applications after you reach functional equivalence in the .NET Framework.
Download the Application Architecture Guide, version 2.0
The Visual Basic Upgrade Companion is able to generate both C# and Visual Basic .NET code from the original Visual Basic 6.0 code base. Thus, when doing a migration project with our tools, you can choose either language. This decision is a challenge itself, especially if you aren't doing any .NET development before the migration. You have to measure the skill set of your staff, and how comfortable they will feel with the transition from VB6 to either language.
Here are some points that are normally thrown around when comparing C# and VB.NET:
- Support: Both languages are well supported by Microsoft, and are first-class citizens on the .NET Framework. Neither one will go the way of the Dodo (or the way of J#, for that matter).
- Adoption: C# seems to have higher adoption than VB.NET. A completely unscientific and in no way statistically valid quick search on the books section of Amazon, however, returned 15,429 results for C#, and 2,267 results for Visual Basic .NET. Most of our customers migrate to C# instead of VB.NET as well. So there may be some truth in this.
- Perception: C# was developed from the ground up for the .NET Framework. This has affected VB.NET's mind share, as C# is viewed as the new, cool language in town. C# is also seen as an evolution of C and C++, which are considered more powerful languages. And we've all heard at least one Visual Basic 6.0 joke - which means that even though VB.NET is a completely different beast, the "VB" name may work against it.
- Familiarity: Visual Basic .NET's syntax is very similar to VB6's, so it is assumed that VB6 developers will feel right at home. This may or may not be true, since they will need to learn all the differences of the new environment, not only the syntax.
- Cost: It also looks like people with skills in C#, on average, earn more than those with skills in VB.NET. This is also something to keep in mind when deciding which language to choose.
.NET allows you to mix programming languages, even on the same Solution. So you could have some developers work in C#, while other work in VB.NET - basically let them use the language they feel more comfortable with. DON'T. This may become a maintenance nightmare in the future. You should definitely standardize on just one language, either C# or VB.NET, and stick with it. That way you'll save time and resources, and overall have a more flexible team.
Also, keep in mind that the biggest learning curve when coming from the VB6 world won't be the object orientation of VB.NET or the curly bracket syntax of C#. It will be learning the .NET Framework. That is what you should plan training for, not for a particular language. Learning the syntax for a new programming language is pretty trivial compared to the effort required to correctly use all the APIs in .NET.
All in all, you can do anything on either language. I personally like C# better, mainly because I started with C, C++ and Java before moving on to .NET development. Coding is C# is "natural" for me. But you can develop any type of application in C# or VB.NET, as there's no meaningful difference under the covers.
When planning the migration of large applications you may want to use a phased approach. This means that as you migrate the first portions of your application to .NET, you will need to keep the interaction with the Visual Basic 6.0 code. Depending on your application's architecture, you can use one of the following approaches:
- Interop Forms toolkit: Now at version 2.0, it simplifies the process of embedding .NET forms and controls inside VB6 applications. It is recommended for GUI-intensive applications
- Binary Compatible .NET DLLs: This technique allows you to expose .NET components through COM. It is recommended for multi-tier apps, especially if you want to migrate the back end before you migrate the front end. It allows VB6 and ASP applications to continue using the same components even after they are migrated to the .NET Framework.
The current version of the Visual Basic Upgrade Companion is able to add binary compatibility information to these components. The VBUC does this automatically to ActiveX DLLs, and it is as easy as activating the "COM Visible" feature in the Upgrade Profile:
Once you have the .NET code, you need to check Register for COM Interop in the Project Properties page in Visual Studio.NET, and then you are all set. Your VB6 and ASP applications will continue working with the newly migrated .NET components, transparently, while they await their turn for a migration.
You can read more about this feature on the COM class exposure page.
We recently did some quick tests on the results of some projects that we just finished migrating to compare the binary size and memory footprint of the resulting migrated .NET application and the original Visual Basic 6.0 application. Here is a brief summary of the results.
Binary Size
We have seen that binary sizes remain very similar or decrease by a small margin when compared to the original Visual Basic 6.0 binaries. There is a small amount of application re-factoring that contributes to this reduction, though, such as consolidating all shared files to a common library (instead of including the same files in several VB6 projects, which increases the code base and binary size).
You do have to take into account the space required by the .NET Framework itself, that varies from 280MB to 610MB.
Memory Footprint
Our observations on the memory footprint of migrated .NET applications, when compared to the original VB6 applications, is consistent to what we've seen with the binaries' size. .NET applications have higher initial memory consumption, since the .NET Framework sets up the stack and heap space at startup, and you have to add the memory required by the JIT compiler. Even with these constraints, a quick revision of applications that we've migrated for customers shows that the memory consumption is, on average, around 10% less than in VB6 (these are no scientific measurements, just based on monitoring memory consumption during the execution of test cases).
We have also seen that .NET normally maintains a more consistent memory usage pattern, while VB6 applications has more peaks where the memory consumption goes up, then back down. This is caused by the .NET Framework holding on to resources until the Garbage Collector runs, and the overall improvements in memory management included in the .NET Framework.
.NET applications have a memory overhead associated with the .NET Framework itself. This is more noticeable in small applications, but overall, is a tradeoff required for running on a managed environment. According to the .NET System Requirements, the Framework requires at least 96MB (256MB recommended) of RAM to run. In our experience, however, you should have at least 512MB (1GB recommended) of RAM to run migrated applications comfortably (on Windows XP).
The performance of a migrated .NET application, when compared to the original VB6 application, is normally very similar or better. The only instances when we have seen a performance decrease is when doing an important re-architecture or when the database engine is changed (from Access to Oracle, for example). Every once in a while we also run into issues with the Garbage Collector, but fortunately they are not that common and are easy to detect.
One thing to keep in mind is the way .NET loads assemblies, and how they are executed. .NET assemblies are compiled to an intermediate language, called CIL (Common Intermediate Language, formerly MSIL). When these assemblies are executed, the default behavior for the .NET Framework is to use a Just-In-Time compiler, which compiles the CIL code for a method to native code "on the fly" the first time the method is called. This implies an overhead on this first call, which suffers from a (normally acceptable) performance impact while the JIT compiler runs. Once a method is compiled, though, it is kept in memory, so the performance of subsequent calls is not affected. Once the code is in memory the performance of the .NET application is normally better than the performance of the VB6 application. You can find more information on JIT here.
It is worth mentioning that you can run ngen.exe on the application to compile the CIL assemblies to native code. This may improve application startup and first run times. Here's an interesting take on whether to ngen or not to ngen.
Check out this performance optimization book in MSDN, called Improving .NET Application Performance and Scalability. It is slightly outdated, but the concepts still apply and are useful to improve the performance of migrated applications.
Today we published a new White Paper, Planning a Successful VB to .NET Migration: 8 Proven Tips. In it, we share some tips on things that you should be aware of when migrating your applications.
This is the first in a series of White Papers we will be releasing in the next months. The idea is to share the knowledge we have accumulated over the years performing Visual Basic 6.0 migrations to the .NET Framework. We have been involved with Microsoft in this type of engagements since the very beginning of the platform, and faced lots of issues in the process. This has shaped our current methodology, which, even though is still improving, has proven itself with solid results (a you can read in the recently released case studies). Hopefully you will find them very useful when faced with a migration task at your organization.