One very common requirement for migration projects is to adapt certain error handling patterns used in a customer’s Visual Basic 6.0 code to the structured error handling provided by .NET, cleaning up the code, improving its maintainability, and, whenever possible, complying with .NET best practices.
The VBUC already converts several commonly used error handling patterns, such as the ones described in this old post. There are, however, situations where the VBUC is not able to recognize a pattern. these usually involve Goto statements, On Error Resume Next, Resume Next or some other construct usually associated with “spaghetti code”. When one of these patterns is encountered, the VBUC does a very basic transformation and generates an EWI so it can be cleaned up through manual intervention later on, such as in the following example:
|
Visual Basic 6.0 Code |
.NET Code |
Private Function <NAME>(<PARAMS>) As <TYPE>
Const MethodName As String = "<NAME>"
On Error GoTo ErrorLabel
<STATEMENTS 1>
On Error GoTo <LABEL>
<STATEMENTS 2>
CleanUp:
<STATEMENTS 3>
Exit Function
<LABEL>:
<STATEMENTS 4>
LogError(MethodName)
Err.Raise 16, , MethodName
ErrorLabel:
<STATEMENTS 5>
LogError(MethodName)
Err.Raise Err.Number, , MethodName
End Function
|
private <TYPE> <NAME>()
{
const string MethodName = "<NAME>";
//UPGRADE_TODO: (1065)
Error handling statement
(On Error Goto) could not be converted.
More Information:
http://www.vbtonet.com/ewis/ewi1065.aspx
NotUpgradedHelper.NotifyNotUpgradedElement(
"On Error Goto Label (ErrorLabel)");
<STATEMENTS 1>
try
{
<STATEMENTS 2>
<STATEMENTS 3>
return result;
}
catch (Exception ex)
{
<STATEMENTS 4>
LogError(MethodName);
throw new System.Exception(
((int) 16).ToString() +
", " + String.Empty +
", " + MethodName);
ErrorLabel:
<STATEMENTS 5>
//UPGRADE_WARNING: (2081)
Err.Number has a new behavior.
More Information:
http://www.vbtonet.com/ewis/ewi2081.aspx
LogError(MethodName);
throw new System.Exception(
Information.Err().Number.ToString() +
", " + String.Empty +
", " + MethodName);
return result;
}
} |
Most of the time it is possible to generate a solution that will correctly convert the error handling pattern, maintaining functional equivalence and meeting any additional coding guidelines from our customers. For the previous example, The VBUC can be customized so the generated code looks as follows:
try
{
try
{
<STATEMENTS 1>
}
catch (Exception ex){
<STATEMENTS 5>
throw;
}
try
{
<STATEMENTS 2>
}
catch (Exception <LABEL>Ex)
{
<STATEMENTS 4>
<LABEL>Ex.Data.Add("ERROR",16);
throw;
}
}
finally
{
<STATEMENTS 3>
}
This example makes some assumptions on the nature of the code and on the intention of the original VB6.0 developer, in particular:
- Errors raised by <STATEMENTS 1> should be handled by <STATEMENTS 5>
- Errors raised by <STATEMENTS 2> should be handled by <STATEMENTS 4>
- <STATEMENTS 3> is cleanup code that should always be executed
- The Exception needs to be thrown again without loosing any information
This is just an example, but the intention is to show what type of customizations can be done. The VBUC transformation engine is very powerful, and, as long as a pattern can be identified, can help you automate the solution to most VB6.0 problems.
Here is a quick way to know if a binary file (*.exe, *.dll, *.ocx, …) has a dependency on the Visual Basic 6.0 Runtime. The trick is to use the Dependency Walker tool to see its dependencies. The dependency you are looking for is the Visual Basic 6.0 runtime library (msvbvm60.dll), and it appears on the tree if you are dealing with a VB6.0 binary:
If you are concerned about the VB6.0 runtime not being supported after Windows Server 2008 and Windows 7, this is a trick that can help you decide whether to keep a particular third party ActiveX component in your application through COM Interop after migrating to the .NET Framework or to start looking for a replacement in case the runtime is no longer available (and thus the component will no longer work).
Dependency Walker is a freeware tool that was included with Visual Studio 6.0, is included in the Windows Support Tools and can be downloaded from the Dependency Walker homepage.
This week we published a new case study on the migration we performed for Banamex, part of Citigroup and one of the largest Mexican banks. In this project we migrated 124 Visual Basic 6.0 and ASP applications from different divisions of the bank to C# and ASP.NET. All in all, we migrated over 5 MILLION LINES OF VB6 AND ASP CODE. This is the largest VB6 to .NET migration we’ve done so far, it was a huge success story – so much that we are now working on the migration of some other applications that weren’t originally included in the scope of the project.
You can read the details here.
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?
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.