In it March issue, Visual Studio Magazine published an in-depth article about legacy migrations called “Unlocking Legacy Code”. This article talks about the challenges faced by companies migrating from Visual Basic 6.0 to .NET, the drivers behind these migrations and the pros and cons of using an automated migration solution.

The article uses BEMAS Software as a case study for successful migration products. I am incredibly happy they are doing as well as they are with the conversion – they are using our tools, and I visited BEMAS about a year and a half ago to train them on the VBUC and help them plan the migration project. I remember they had a lot of conditional statements (by “a lot”, we are talking thousands of different combinations), as mentioned in the article:

"We also ran into some issues with the conversion tool because early on in the VB code we did a lot of #ifs, which means that the code acts differently depending on how you compile it," Pownall adds. BEMAS worked with ArtinSoft so that VBUC would recognize those instances and convert the code correctly.

It was quite a challenge to get it to convert, since the default behavior of the VBUC is to convert the code inside the conditional statement that evaluates to “TRUE”. Commenting out the conditionals wasn’t going to work either, since that would cause multiple variable declarations and other semantic errors that caused issues during the migration of this particular code. In the end we worked together with BEMAS, and with heavy involvement of the VBUC development team, we managed to modify the tool enough to get the code converted correctly.

Another very interesting item mentioned by Steve Pownall in the article, that I want to talk about some more, is the fact that even though the code came through very cleanly, it didn’t have the .NET architecture they were aiming for so they had to “The dev team had to massage or opted to rewrite the rest of the codebase manually in C# and .NET 3.5 using VS2008.”. This is a very important point, since the overall architecture of the code will remain as it was in VB6.0. The migration, however, gets you quickly to a stable .NET codebase that you can then rework to make it take advantage of the latest features of the .NET Framework. In our experience, this path (migrate, then enhance) is the one with the lowest risk, and it allows you to reduce the time to market for your applications by a wide margin. This is important to keep in mind, since we, as developers, always want to improve the code base – it is part of our professional formation, and I would say, part of our nature – but we sometimes fail to grasp the additional risk this implies. The migration is very controlled process, that gets you predictable results in a short time. Enhancing the application after the migration may seem like duplicating work (and indeed, there are enhancements that can be done during the migration process) but it guarantees that you will get a .NET in the allocated timeframe and budget, not to mention the cost advantage.

Read the complete article, Unlocking Legacy Code at Visual Studio Magazine.

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:

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.

Back when it was first announced I made a couple of posts about Windows 7 XP Mode (available here and here). Now that I’ve been using almost every day for the past few months, I wanted to revisit the topic and write about my hands-on impressions. In this post I’ll show how applications that run under XP Mode integrate with the regular Windows 7 environment.

The integration features of XP Mode work really well, for the most part. Applications installed in the Virtual Machine appear right there on the Start Menu:

  
The Start menu gains a “Windows XP Mode Applications” folder under “Windows Virtual PC”,
which holds all apps installed in the XP  Mode virtual machine (click picture to enlarge)

And even show up when searching, which is extremely convenient.

 
The Quick Search functionality of the Start menu covers
XP Mode Applications. (click picture to enlarge)

When you launch applications, Windows starts up the XP Mode virtual machine behind the scenes, showing a progress toolbar instead of XP’s boot up sequence.

Windows XP Mode virtual machine startup. Notice it is running under
Windows Virtual PC. (click picture to enlarge)

Once the application starts up, you’ll notice it is running on XP Mode since the UI uses XP’s windows, instead of Aero:

Visual Basic 6.0 on XP mode, complete with default Windows XP “Luna” theme. (click picture to enlarge)

The following screenshot shows this more clearly, by contrasting the Visual Basic 6.0 IDE running under XP Mode and Visual Studio 2008 running directly on the Windows 7 desktop.:

Visual Basic 6.0 on XP mode (Luna theme) vs. Visual Studio 2008
on Windows 7 (Aero Glass theme). (click picture to enlarge)

Another VERY NICE feature is that the "My Documents” folder is transparently mapped to Windows 7’s “Documents” library:

 
Visual Basic 6.0 on XP mode Open Project dialog showing the My Documents folder.
Notice the same contents on the Documents library in Windows 7. (click picture to enlarge)

These integration features of XP Mode make life much easier for legacy applications, but it is far from perfect. In the next post I’ll mention the annoyances I’ve run into while working with XP Mode.

A quick post to let you all know that the recording of last week’s webcast I did on compatibility options for Windows 7 is now online. In this webcast I briefly covered different compatibility options available for Windows 7, mentioning things like virtualization (such as XP Mode) and Remediation, and the focusing on the benefits of using automated migration tools to get the application off VB6.0 and into .NET so it can take advantage of the new APIs available in Windows 7 (Taskbar API, touch API, etc).

See the recording here

Today we unveiled something that we have been working on for the past few months – we’ve formed a strategic alliance with Gizmox to offer migrations from Visual Basic 6.0 to the web. This offering uses the Visual WebGui Framework to maintain the same user interface as the original application, inside an either ASP.NET or Silverlight application running on the web. We’ve started the process for customizing the Visual Basic Upgrade Companion to generate code that works with the Visual WebGui framework, and have been working very closely with Gizmox to determine the best approach for doing this type of migration.

We are very exited about this offering, since it is something that has been requested by our customers for a while. A very common scenario we run into is organizations that host their own application, and access them using “remote desktop”-like solutions such as those from Citrix or Terminal Services. Moving these application to a web-based environment with this solution allows these organizations to save money on licensing costs while preserving the rich UI from the original application. And, in the future, these applications can be easily hosted on a cloud computing provider, giving the ability to scale without having to heavily invest in additional hardware or licenses.

Here is a short video I recorded that shows how applications are converted tot he web, including the final result running as an ASP.NET application.

Link to the video on the external site

Here is a link to the press release announcing the alliance: ArtinSoft and Gizmox Announce Strategic Alliance to Migrate Visual Basic 6.0 Applications to the Web

And you can read more about the benefits of this solution in this webpage: Upgrade your strategic Visual Basic 6.0 assets to a web-based platform

Next Monday, August 17, I will be presenting a Webinar along with Microsoft for the Latin America region on how you can use several options to get your VB6.0 applications to run on Windows 7 AND get the Windows 7 logo. The webinar will be in Spanish, and covers the business reasons for the migration, the benefits of using in the .NET Framework, alternatives, and information (+demo) of the VBUC.

Here’s the link so you can register for the Webinar:

Actualiza tus apliaciones y consigue el logo de Windows 7
Fecha: 17 de agosto 05:00 p.m. Ciudad de México
Register for the Webinar

A quick post to let everybody know that you can now follow us on twitter. To do so, you just need to follow @artinsoft, or add “artinsoft” in your favorite Twitter client. In this account we are posting news and articles related to software migrations, and you can also use it to communicate directly with us in case you have any question or want to give us any feedback.

ArtinSoft Twitter page

We just posted a new case study about how an Italian company, Wolters Kluwer Italia, managed to successfully migrate its flagship Accounting and Financial services product from VB6.0 to Visual Basic .NET, using a customized version of the Visual Basic Upgrade Companion.

This Wolters Kluwer is a case where the VBUC customizations performed by ArtinSoft helped them achieve two very important goals: first, to radically speed up the overall migration project, by having the VBUC do particular transformations that otherwise would have required manual changes, and second, to meet very specific requirements for the migration, such as using having the VBUC generate .NET code that used their own controls, do additional refactoring to the code, and other architectural customizations made possible by the VBUC engine.

Read the case study: Wolters Kluwer licenses the Visual Basic Upgrade Companion to quickly and cost-effectively modernize its flagship Accounting/Fiscal software product

One question commonly asked by our customers is how both duplicate (same file copied in several projects) and shared files (one copy of the file referenced from multiple projects) are counted. If you create a migration solution using the VBUC, it counts the lines of code in a project (Lines column):

This number displayed in the VBUC includes all the lines of code from files referenced in the *.vbp project. This means that it counts shared files and duplicate files each time they appear. This may increase the final amount of lines of code of the total solution. If you do need to find out the number of lines of code counting these files once, we offer you two options:

The first one is to download and run our new Visual Basic 6.0 and ASP Assessment Tool. This brand-new assessment tool considers both Shared and Duplicate files and counts both accordingly in separate columns.  As shown in the screenshot below, the Assessment Tool identifies “Potential Duplicates”, which are files that have the same name and the same amount of effective (code + design) lines of code. In practice, they are normally the same file copied over several projects. You should note, however, that there may be small changes that keep the same amount of code (assignments, calls to different functions, etc), so there is no guarantee they are exactly the same. FYI, this was done to speed up the analysis process. In the future we will add additional heuristics to eliminate the possibility of false positives.

The second option is to use the same VBUC, but run a detailed analysis using the “Assessment” option. This can be executed from the main menu by selecting Upgrade->Assessment:

This is a more exhaustive assessment than the one executed by the VB6.0/ASP Assessment Tool, and takes much longer to execute. This assessment will not create an HTML report (like the VB6.0/ASP Assessment Tool), but you can open the detailed line count report produced (Assessment_LOC_Report.xml) using MS Excel 2003 or higher.

When either testing the trial version of the VBUC or actually running the migration tool on your project, there are a few things that you should check to ensure the best possible conversion. These are:

• Project root: Make sure all projects are stored under a one “root” common directory. The VBUC migrates all Visual Basic 6.0 projects (*.vbp) found in a directory structure, including subdirectories, from one common root. You can read more information about setting up the folder structure in the VBUC Quick Start Guide.
• Third-party Components: The VBUC requires that all third party components are correctly registered. Also, very important, ensure you correctly install all licenses for the components. Not including these licenses will not allow the VBUC to load and identify the PMEs (Properties, Methods and Events) and correctly either apply the necessary maps or generate the corresponding COM Interop wrappers.
• Compile all projects: Make sure all projects compile correctly and that all the references between the output (EXE/DLL/OCX) of a project and the referenced component in another project match up. This will allow the VBUC pick up the references automatically, reducing the amount of migration warnings and thus minimize the work required to set up the migration solution. The VBUC Quick Start Guide contains additional details on the importance of this step.

In the last couple of months we’ve done several significant updates to the website that I think are worth commenting about. Here is a quick rundown of what has changed:

• Visual Basic Upgrade Companion Online Documentation: Back with the release of version 3.0 we also went live with the vbtonet.com website, a centralized resource for all information about the VBUC. It contains useful information such as a description of the features of the VBUC, a knowledge base with solutions to common migration problems, the VBUC Quick Start Guide, several How-To’s and other general information about the tool and migration projects in general.
• Updated Services offering: We completely revamped the Migration Services website. You can now get a general overview of our migration services offering, obtain a quick VB Migration Project Ballpark estimate and check out the necessary steps for engaging our services. The ballpark can obviously vary, and sometimes significantly as requirements for a migration are further refined and all applications are different, but normally migrations projects are within the same order of magnitude as the numbers produced by this page.
• Visual Basic Upgrade Companion Trial download: You can download, as before, a fully functional trial of the Visual Basic Upgrade Companion Developer Edition, limited to 10,000 Lines of Code with migration solutions up to 2,000 Lines of Code in size, or request a personalized trial of the Visual Basic Upgrade Companion Enterprise Edition.
• Purchase Licenses Online: The biggest addition we’ve done to the site is that now it is possible to purchase licenses for both the VBUC Developer and Enteprise Editions up to 150,000 lines of code directly, online, from this link. This was motivated by the success we’ve had with selling licenses for the VBUC DE on the web since January. Given the requests of our customers, we decided to both expand the amount of offerings in terms of lines of code allowed per migration with the Developer Edition (from 50,000 to a max of 150,000, plus a 25,000 LOC option) and to make available licenses of the Enterprise Edition in that LOC range as well.

We hope you find this new information we published useful, and please add a comment to this post or send me a message with your thoughts on the new changes and if there’s anything you would like to see on our site.

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 past couple of week I’ve been contacted by a couple of developers concerned with Microsoft’s decision to stop supporting the Visual Basic 6.0 IDE, but to continue support for the Visual Basic runtime and some support libraries in Windows 7 and 2008. This made me think about revisiting the topic with new information and changes since February, when I wrote this post.

It is obvious that Microsoft has been trying to drop support for VB6.0 for a while now. They have extended it a couple of times, and they say they are committed to "make sure the IDE works" for the lifetime of Vista and Windows 2K8. But here is an important part of the support statement that is worth highlighting:

“VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS.  Developers can think of the support story for Vista being the same as it is for Windows 7.  However there are no plans to include VB6 runtime in future versions of Windows beyond Windows 7.”

This means that the next version of Windows will very likely not include the VB6.0 runtime files. This has obvious implications if you have a  large application that will require several person-years of effort to migrate (or rewrite, if you decide to go that path). There are also some additional implications on the components you are using, since they may have a dependency on the VB6.0 runtime and thus may not work, even if the rest of you application is already in .NET and using these components through COM Interoperability. Just to be sure I’m not spreading unnecessary panic, Windows 7 is not even out yet, and it will be covered by Microsoft’s OS support policies, so you are good for at least the next five years. If you think the effort to move away from this platform will take longer than (or at least close to) this timeframe, make sure you start evaluation your options soon.

Another important thing to keep in mind is that the VB6.0 runtime files are 32-bit only. Starting with Windows Server 2008 R2, 32-bit mode (WOW64) is optional, and the next version of Windows Server (tentatively due in 2011-2012) will be 64-bit only. This affects both server-side components, ASP, and client-side applications running on the server through Terminal Services, Citrix, or any other remote access technology (though they may able to run using WOW64, albeit requiring an extra configuration step).

A big change since I wrote the last post is that now Windows 7 includes a complete XP virtual machine to run legacy apps, known as XP Mode. I already made a couple of posts on this, and basically, this seems to be a good intermediate steps to “buy some time” before companies move their applications to supported platforms.

As I recommended in the previous post, you should read the  "Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7". Also, the Microsoft Product Lifecycle details the specific dates when support ended for VB6.0.

This is a very simple configuration option that can really help you speed up the process of reviewing all migration EWIs (Errors, Warnings and Issues) when working with migrated code. In Visual Studio, you can use the Task List panel to keep track of a list of items (tasks) you need to go through. This Task List can be configured to show migration EWIs, as shown in the following screenshot:

For this to work, in the Visual Studio IDE, select Tools->Options from the main menu. In the Options window, navigate to Environment->Task List. Here, you’ll need to add the four types of EWIs inserted by the VBUC, along with their priority:

• UPGRADE_ISSUE: Issues appear when there is some migrated code that is very likely to cause a compilation error. My recommendation is that you add it with Normal priority
• UPGRADE_NOTE: Notes are basically information messages. For example, if the VBUC detects dead code, it will comment it out and add an UPGRADE_NOTE comment to make sure the developer understand why it was removed. This can be added as Low priority, since they very rarely require manual intervention after the migration.
• UPGRADE_TODO: Partially upgraded code. These EWIs should be added as high priority, since they indicate the developer needs to perform some additional work to complete the migration.
• UPGRADE_WARNING: Warnings appear when there is a difference in behavior between the VB6 code and its .NET equivalent. The solution provided normally works, but there are some scenarios where additional manual intervention may be required (most likely from runtime errors). I normally add them to the Task List as Normal priority.

With this configuration, you can very easily and quickly browse through all the EWIs in a file, and determine which ones actually require you to perform some manual work, and which ones can be either removed because the line they are tagging will work, or if their verification will be deferred until functional testing takes place.

You can read more about VBUC’s Errors, Warnings and Issues here, and about Visual Studio’s Task List at this link.

The business-oriented newspaper, El Financiero, just published an article talking about the advantages of performing a migration instead of a manual rewrite. The article talks about how Banamex (part of Citigroup) saved an estimated 80% of the cost when compared to rewriting their 125 applications, totaling over 5 million lines of code. It also talks about the advantages of being in .NET, including how it allows customers to rapidly respond to changes in market conditions.

You can read the original article in Spanish at the following link: Cambiar el software en estos tiempos de crisis or read the Google Translation in English. You can also check out the Banamex/Citigroup case study at the following link: Banamex - Citigroup turns to ArtinSoft to ensure compliance and business continuity through massive migration to C#.NET