Performance of .NET Migrated Applications

17. December 2008 05:10 by Jaguilar in General  //  Tags: , , ,   //   Comments (0)

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.

Tips for Planning a Migration Project

16. December 2008 06:58 by Jaguilar in General  //  Tags: , ,   //   Comments (0)

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.

So, What's New in the Visual Basic Upgrade Companion version 2.2?

11. December 2008 12:09 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

As I mention in a post last week, we recently released version 2.2 of the Visual Basic Upgrade Companion. The previous version, 2.1, added some new things, but focused mostly on "under the covers" improvements, and fixing several issues reported with version 2.0. However, for this release, we do have several exciting new features that should make migrations from Visual Basic 6.0 go much smoother. Among these, we can mention:

Custom Mappings
The Visual Basic Upgrade Companion enables the user to define customized transformations for the upgrade process execution. This technique allows to implement coverage for non-supported legacy components and to enhance and fine-tune the existing support. I already covered Custom Maps on this post and you can read more about this on the Custom Maps page.

Data access - new flavors available
The Visual Basic Upgrade Companion converts the data access model on your VB6 application (ADO, DAO, RDO) to ADO.NET, using the either SQLClient data provider or the classes defined in the System.Data.Common namespace. Using the latter will allow your migrated application to connect with most major .NET database providers. Version 2.2 added support for the automated migration of DAO and RDO to ADO.NET, and greatly improved the migration of ADO to ADO.NET. More information here.

Naming conventions refactoring
This  feature  lets  the  end-user  migrate  his  Visual  Basic  6  code  to  VB.NET  or  C#  with  standard Naming Conventions.  This  feature  is  a compound of common naming conventions for .NET languages, and use  standard  coding  practices for  C# and VB.NET. You can find more information on this and the next feature in this page.

Renaming mechanism
The  renaming  feature changes  the name of an  identifier and all of  its  references  in order  to avoid conflicts with another name. Some of the conflicts solved by the VBUC are:

  • Keywords: The VBUC must rename the names that are the same as keywords from Visual Basic .NET and C#. Moreover,  the  VBUC  should  take  into  account  the  target  language  (Visual  Basic.NET  or  C#)  to recognize the keywords that apply for each case.
  • Case sensitive issues (C#): Visual  Basic  6  is  a  case  insensitive  language,  but  C#  is  not.  The  VBUC must  correct  the  name references used with different cases to the case used in the declaration.
  • Scope conflict: This is necessary when a Type declaration element has the same name as the type declaration. If  this case  is detected  the element declaration must be  renamed along with  the  references  to  this type element.
  • Conflicts with .NET classes: This section applies for Forms and UserControls, mainly, because they could declare some member names that are part of the corresponding class in .NET (in this case System.Windows.Forms.Form & System.Windows.Forms.UserControl).  These  members  must  be  renamed  in  order  to  avoid  any conflict.

User Controls and Custom Properties
In Visual Basic 6.0  user  controls  expose  their  programmer-defined  properties  in  the  property  list  on  the designer window. These user properties can be configured to be displayed in a specific category and based on  these settings. The Visual Basic Upgrade Companion can determine  the most appropriate type  and  settings  for  the  resulting  properties  to  have  functional  equivalence with  the  original VB6 user property. I plan on elaborating on this feature in a future blog post.

Visual Basic Upgrade Companion version 2.2 released!!

2. December 2008 19:56 by Jaguilar in General  //  Tags: , , , , , ,   //   Comments (0)

After several months of hard work, we are proud to announce the release of version 2.2 of the Visual Basic Upgrade Companion. This version includes significant enhancements to the tool, including:

  • Custom Maps: You can now define custom transformations for libraries that have somewhat similar interfaces. This should significantly speed up your migration projects if you are using third party controls that have a native .NET version or if you are already developing in .NET and wish to map methods from your VB6 code to your .NET code.
  • Legacy VB6 Data Access Models: for version 2.2 we now support the transformation of ADO, RDO and DAO to ADO.NET. This data access migration is implemented using the classes and interfaces from the System.Data.Common namespace, so you should be able to connect to any database using any ADO.NET data provider.
  • Support for additional third party libraries: We have enhanced the support for third party libraries, for which we both extended the coverage of the libraries we already supported and added additional libraries. The complete list can be found here.
  • Plus hundreds of bug fixes and code generation improvements based on the feedback from our clients and partners!

You can get more information on the tool on the Visual Basic Upgrade Companion web page. You can also read about our migration services, which have helped many companies to successfully take advantage of their current investments in VB6 by moving their applications to the .NET Framework in record time!

Alright, Visual Basic 6 Application run on Vista, but where's the IDE?

21. November 2008 10:07 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

Do you remember this classic bit, a pretty bad joke from the end of the movie "Coming to America":

"A man goes into a restaurant, and he sits down, he's having a bowl of soup and he says to the waiter: "Waiter come taste the soup."
Waiter says: Is something wrong with the soup?
He says: Taste the soup.
Waiter says: Is there something wrong with the soup? Is the soup too hot?
He says: Will you taste the soup?
Waiter says: What's wrong, is the soup too cold?
He says: Will you just taste the soup?!
Waiter says: Alright, I'll taste the soup - where's the spoon??
Aha. Aha! ..."

Well, the thing is that this week, when I read this column over at Visual Studio Magazine, this line of dialog was the first thing that came into my mind. First of all, we have the soup: according to the Support Statement for Visual Basic 6.0 on Windows®Vista™and Windows®Server 2008™, the Visual Basic 6.0 runtime support files will be supported until at least 2018 (Windows Server 2008 came out in 27 February 2008):

Supported Runtime Files – Shipping in the OS: Key Visual Basic 6.0 runtime files, used in the majority of application scenarios, are shipping in and supported for the lifetime of Windows Vista or Windows Server 2008. This lifetime is five years of mainstream support and five years of extended support from the time that Windows Vista or Windows Server 2008 ships.  These files have been tested for compatibility as part of our testing of Visual Basic 6.0 applications running on Windows Vista.

Then, we have the spoon, taken from the same page:

The Visual Basic 6.0 IDE

The Visual Basic 6.0 IDE will be supported on Windows Vista and Windows Server 2008 as part of the Visual Basic 6.0 Extended Support policy until April 8, 2008.  Both the Windows and Visual Basic teams tested the Visual Basic 6.0 IDE on Windows Vista and Windows Server 2008.  This announcement does not change the support policy for the IDE.

So, even though you will be able to continue using your Visual Basic 6.0 applications, sooner or later you will need to either fix an issue found in one of them, or add new functionality that is required by your business. And when that day comes, you will face the harsh reality that the VB6.0 IDE is no longer supported. Even worst so, you have to jump through hoops in order to get it running. If you add the fact that we are probably going to see Windows 7 ship sooner rather than later, the prospect of being able to run your application but not fix it or enhance it in a supported platform becomes a real possibility. So make sure that you plan for a migration to the .NET Framework ahead of time - you don't want to hear anybody telling you "Aha. Aha!" if this were to happen.

Starting a Visual Basic to .NET migration with the Visual Basic Upgrade Companion in 5 Simple Steps

17. November 2008 05:23 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

So you now have a license of the Visual Basic Upgrade Companion, you open it up, and you don't know what now to do. Well, here are 5 simple steps you can follow to get the most out of the migration:

  1. Read the "Getting Started" Guide: This is of course a no brainer, but well, we are all developers, and as such, we only read the manual when we reach a dead end ;). The Getting Started guide is installed alongside the Visual Basic Upgrade Companion, and you can launch it form the same program group in the start menu:
               GettingStarted
  2. Create a New Upgrade Solution: the first step for every migration will be to create a new VBUC Migration Solution. In it, you need to select the directory that holds your sources, select where you want the VBUC to generate the output .NET code, and the location of the binaries generated and use by the application. This last bit of information is very important, since the VBUC extracts information from the binaries in order to resolve the references between projects and create a VS.NET solution complete with references between the projects:
               GettingStarted2
  3. Select the Target Language: One of the most significant advantages of using the Visual Basic Upgrade Companion is that it allows you to generate Visual Basic.NET or C# code directly. This can be selected using the combo box in the Upgrade Manager's UI:
               GettingStarted3
  4. Create a Migration Profile: The Visual Basic Upgrade Companion gives a large degree of control to the end users on how the .NET code will be generated. In addition to the option of creating either C# or VB.NET code, there are also a large amount of transformations that can be turned on/off using the profile manager. Starting with version 2.2, the Profile Manager recognizes the components used in the application and adds a green checkmark to the features that apply transformations to those components. This simplifies profile creation and improves the quality of the generated code from the start:
               GettingStarted4
  5. Select the Code Typing Mechanism: the VBUC is able to determine the data type for variables in the VB6.0 code that are either declared without type or as Variant. To do this, for each project included in the migration solution you can select three levels of typing: Full Typing, Local Typing or No Typing. Full Typing is the most accurate typing mechanism - it infers the type for the variables depending on how they are used throughout the project. This means that it needs to analyze the complete source code in order to make typing decisions, which slows the migration process and has higher memory consumption. Local Typing also infers data types but only within the current scope of the variable. And No Typing leaves the variables with the same data types from the VB6.0 code:
               GettingStarted5

After going through these 5 steps, you will have an Upgrade Solution ready to go that will generate close to optimal code. The next step is just to hit the "Start" button and wait for the migration to finish:

GettingStarted6 

Visual Basic 6.0 to C# Case Studies

11. November 2008 06:29 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

A few days ago we posted some new case studies to our site. These case studies highlight the positive impression that the capabilities of the Visual Basic Upgrade Companion leave on our customers when we do Visual Basic 6.0 to C# migrations.

The first couple of them deal with a UK company called Vertex. We did two migration projects with them, one for a web-based application, and another one for a desktop application. Vertex had a very clear idea of how they wanted the migrated code to look like. We added custom rules to the VBUC in order to meet their highly technical requirements, so the VBUC would do most of the work and speed up the process. Click on the links to read the case studies for their Omiga application or for the Supervisor application.

The other one deals with a Texas-based company called HSI. By going with us they managed to move all their Visual Basic 6.0 code (including their data access and charting components) to native .NET code. They estimate that by using the Visual Basic Upgrade companion they saved about a year in development time and a lot of money. You can read the case study here.

Categories