Today we formally released version 3.0 of the Visual Basic Upgrade Companion, including both the Enterprise and Developer Edition of the migration tool. This is a significant new release, which has improved the efficiency of the conversion tool by reducing the amount of work required to the the applications to functional equivalence by over 30% (and more in some cases). All migration improvements are based on the feedback from the experiences of both our clients and our own consulting team, and we are very happy the changes have such an effect. I already talked about specific new features on a previous post.
Also, today we went live with a new companion website to the VBUC at www.vbtonet.com. This repository of information should help you in all aspects of the migration, and includes both best practices for, for example, finding customization opportunities in the code, and both overall strategies and detailed examples on how to solve migration issues. This site is tightly integrated with the VBUC, and migration issues identified in the code by the tool will contain a link to latest information to help you solve the issue, like the following example:
'UPGRADE_TODO: (1067) Member MyMember is not defined in type Variant. More Information: http://www.vbtonet.com/ewis/ewi1067.aspx
This library of information will continue growing over time, so make sure you come back often during your migration project to check out the latest content.
You can read the official press release here.
A couple of days ago we made available the final release candidate for version 3.0 of both the Visual Basic Upgrade Companion Enterprise Edition and Developer Edition. You can now directly download a trial of the VBUC Developer Edition on the trial download page, or request a trial of the Enterprise Edition on this page.
I need to mention an obligatory disclaimer saying this is the final Release Candidate, so, unless we find something at the last minute, it should be the same version officially released within a week or so. We need your help to verify we won’t find anything by downloading it and trying it out. :)
I already covered some of the features of this version on a previous post. There was significant improvements in several areas from version 2.2, which should help you achieve even greater productivity on your migration projects.
As I blogged before, the release of the VB Upgrade Companion v3.0 is due within the next few weeks. In this version we concentrated on three major areas:
- Automation: We analyzed the data from several million lines of code to determine the most common causes of manual intervention, and, by making some strategic changes to the way the code is generated, managed to reduce the amount of both EWIs (Error, Warning and Information messages) and compilation errors significantly on large (>1 million Lines of Code), complex applications. Also, depending on the VB6 features used, the VBUC now automates the migration of even more smaller applications and components completely!
- New Features: The VBUC v3.0 also contains additional features, such as the migration of the IsMissing statement and increased support for additional third party components. We are also integrating the VBUC with brand new online documentation resources that should help you as you perform the migration!
- Code Quality: The Visual Basic Upgrade Companion always tries to generate high-quality code that looks as if it was originally written in .NET. This increases the maintainability of the migrated application, and allows developers joining the project at a later date to very quickly start working on the codebase. Because of the great differences between Visual Basic 6.0 and VB.NET/C#, however, achieving this goal is not always possible. For this release we continued increasing the quality of the migrated code, including minor refactorings to control structures, and adding things like support for translating additional error handling statements to try/catch statements.
All of these was supported by some significant changes we did under the hood, which should make it easier to add new features in the future (including customer-specific customizations) and reduced the memory footprint significantly, while increasing migration speed. Watch this space for more details as the release date approaches!
We are currently wrapping up all development effort to focus on the final testing and stabilization of the next version of the Visual Basic Upgrade Companion, both Enterprise and Developer Editions, version 3.0. For this version we focused more on architecture improvements, preparing the code base for more significant upgrades in the future. We still we managed to add some great features such as:
- Enhanced resolution of default properties: By both improving the typing engine of the VBUC and generating additional code for runtime resolution of default properties, we were able to reduce the total amount of EWIs present in the code by 30%!
- Improved support for API Calls: Most API calls should now work correctly. There are still a couple of issues, but they should be sorted out by the final release
- IsMissing migration: We now correctly support the migration of the IsMissing statement.
- Enhanced support for the migration of common controls, such as Imagelist, Listview, Statusbar, Toolbar and Treeview, to native .NET components. We now correctly convert most functionality of these controls to .NET
- A greatly enhanced Assessment Mode to better estimate the effort required to perform a migration project
- Significant performance improvements and memory footprint
- Over 150 code generation improvements based on feedback from projects we’ve done, our clients and partners
We are currently conducting a limited Beta program for the VBUC Developer Edition v3.0. If you are interested in participating, drop me a line and I’ll get back to you with further instructions.
Edit: The upcoming version of the VBUC will be version 3.0 - this release represents a leap in the level of automation and additional features we managed to squeeze in, and thus deserved a new major version number. I will post additional details on the different features as the final release date approaches.
This week Microsoft updated its support statement for Visual Basic 6.0 to include the upcoming Windows 7. Even though the original idea was to not support VB6 in Windows 7, given the outstanding demand, the runtime WILL BE included in the OS.
To summarize, the support status of the different Visual Basic 6.0 components is:
- Visual Basic 6.0 IDE: Unsupported as of April 8, 2008.
- Visual Basic 6.0 Runtime: Supported for the lifetime of Windows Vista, Server 2008 and 7. *This is the big change in the Support Statement*.
- Visual Basic 6.0 Runtime Extended Files: The supported versions are here.
Even though the runtime components will be supported in Windows 7, it is important to consider the implications of the IDE not being supported (as I described in this post). There are also additional advantages of moving to .NET such as 64-bit support (VB6 apps are 32-bit only) and all the productivity, maintainability and deployment gains provided by the platform.
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.
A quick post to let you all know that we now have a trial available for download of the Visual Basic Upgrade Companion Developer Edition. To obtain the trial you need to fill in your information here, and we will email you the download link and the necessary licensing information to activate the trial.
The trial will allow you to migrate up to 2,000 lines of code simultaneously, and has a limit of 10,000 lines of code total – which means that every time you migrate some code, the amount of lines you migrated are discounted from the 10,000 total.
So don’t wait and download the VBUC DE trial now!
Remember that you can also request a trial for the Enterprise Edition of the Visual Basic Upgrade Companion at this page. You will need to run the Assessment Tool first, and based on the results we will send you a custom trial for a portion of your application.
Several times I’ve mentioned the Type Inference feature of the Visual Basic Upgrade Companion. The main objective of the component that we call the “Typer” was to eliminate Upgrade Issue 1037 (Couldn't resolve default property of object ‘x’) that appeared then the VBUC wasn’t able to correctly determine the data type of a variable and consequently couldn’t resolve its default property.
Even though dealing with EWI 1037 was the design goal, having a typing mechanism in the VBUC allowed us to improve a great deal of transformations. One particular feature that benefitted from it was the migration of VB6 Enums. To illustrate this, let’s look at an example.
First, let’s see some VB6 code (doesn’t really do much except use Enums):
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim enumUsage As Integer
13:
14: Public Sub MyMethod()
15: enumUsage = EnumValue1
16: enumUsage = 4
17: If enumUsage = EnumValue4 Then
18: enumUsage = EnumValue7
19: End If
20: If enumUsage = 7 Then
21: enumUsage = 5
22: End If
23: End Sub
After running the code through the VB Upgrade Companion we get this:
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim EnumUsage As Myenum
13:
14: Public Sub MyMethod()
15: EnumUsage = Myenum.EnumValue1
16: EnumUsage = Myenum.EnumValue4
17: If EnumUsage = Myenum.EnumValue4 Then
18: EnumUsage = Myenum.EnumValue7
19: End If
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
22: End If
23: End Sub
The VBUC performs some very subtle transformations to improve the quality of the generated code. Let’s look at them in detail:
First of all, the usage pattern for the variable EnumUsage is analyzed by the Typer, and it determines that it is always used to store a value of the Myenum Enum. Thus, it infers that the correct data type should be Myenum instead of Integer, as seen in line 12:
12: Dim EnumUsage As Myenum
Since the Typer keeps track of the different ways in which a variable is used, and of the values that are assigned to it, it provides information to the VBUC so it can replace the assigned values with the corresponding enumeration. This applies even for comparisons – the code is translated from:
16: enumUsage = 4
...
20: If enumUsage = 7 Then
21: enumUsage = 5
to (notice the if in line 20):
16: EnumUsage = Myenum.EnumValue4
...
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
This is just one of the features that we have worked on over time to improve the quality of the code generated by the VB Upgrade Companion. It was built on top of the functionality provided by the Typer, and works with both VB6 built-in and user-declared enumerations. As shown in the example, this makes the code easier to maintain, and even looks as if it was written originally in .NET. :)
I know this is completely off-topic to what I normally blog about, but I’ve been having problems this past couple of days when trying to checkout a document from SharePoint using Internet Explorer 7. It crashes every single time – which has been a very frustrating experience, to say the least. I have no idea what caused it to (mis)behave this way. Anyway, turns out the fix was incredibly easy:
- Close all IE7 Windows
- Run Microsoft Office Diagnostics from Start->Programs->Microsoft Office->Microsoft Office Tools
- Click on Run Diagnostics, wait a few minutes, and you should get a dialog saying that 1 repair was performed:
- Continue using SharePoint normally
FYI, I am using MS Office 2003 and Windows SharePoint Services 3.0.
As a Visual Basic 6.0 developer you may want to become yourself familiar with the .NET platform before putting it into production (and making the corresponding investments). In this blog post I wanted to give some pointers to commonly used resources that can help you in that regard.
To run one of the latest Microsoft operating systems you can take advantage of the VHD Test Drive program that I blogged about some time ago. Through this program you have access to a large number of OS configurations that you can try out for a limited time. The ones I would recommend to get started are the Windows Vista 30-Day Eval VHD, the Windows Server 2008 Evaluation, and the Microsoft Windows Server 2003 R2 Enterprise Edition VHD. Remember you need either Virtual PC, Virtual Server or Hyper-V in order to run the virtual machines.
You’ll also need to install Visual Studio 2008, and for this you can either install the Express Editions (which have some limitations, but are free), or a 90-day trial version of Visual Studio 2008 Professional Edition or Visual Studio Team System 2008 Team Suite. Another alternative is to download a full virtual machine with Visual Studio Team System 2008 Team Foundation Server installed.
Also, to get familiar with specific .NET features, you can take advantage of the free e-book offer and the additional content currently up at Microsoft Visual Studio 2008 Learning Portal.
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.