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

Yesterday TechNewsWorld published an article called Planning a Migration Route From Visual Basic 6 to .Net, which discusses some aspects of a report by the Aberdeen Group. The article contains lots of valuable information for those of you considering moving your VB6.0 applications to .NET, by giving a very good idea on the best practices performed by the “Best-in-Class” organizations. I wanted to touch briefly on some of the points from the article, and how it matches our experience helping Fortune/Global 1000 companies upgrade their applications to the latest technology.

Something that is consistent with what we’ve seen is that 33% of the respondents from Best-in-Class and 15% of the “All Others” organizations engage a third party to assist with the migration. We at ArtinSoft, with our Consulting Services group, and along with our world-wide partners, have seen this as a growing trend, and have accumulated a vast a mount of experience that can be leveraged by these organizations to move away from legacy environments.

Also, as part of our migration methodology, we promote a controlled process that first brings your VB6.0 application up to Functional Equivalence in .NET, and then you can use this as a base to enhance an improve your investment. For many clients we also use the extensibility capabilities of the Visual Basic Upgrade Companion to prepare the source code for these enhancements by automating specific architectural modifications required by our customers. These modifications represent an enhancement in itself, and also leave the code ready for further changes by making sure it meets all the practices and coding standards of the organization. The Vertex Omiga and Supervisor Case Studies are a good example in this regard – and we’ve done other migrations with even more important customizations that, unfortunately, I can’t mention directly.

Finally, I want to quote the following text from near the end of the article:

“The research shows that Best-in-Class companies are six times more likely than all other companies to use code conversion or automated porting tools in order to help accelerate part of the migration process.”

You can read our case studies that show this is in fact the case, and we have helped many organizations save time and resources when performing migrations aided by using the Visual Basic Upgrade Companion.

Yesterday I blogged about Windows 7’s XP Compatibility Mode, and have some additional pieces of information that I consider interesting if you are considering using it in the future:

• First of all, not all CPUs would be able to use XP compatibility mode. Take a look at this page over at Tom’s Hardware, and the post over at Ed Bott’s blog. I think the image halfway down the page on the second link speaks for itself – you probably won’t be able to know if the deployment target for your application supports XP Mode or not, which can complicate the installation experience.
• The second bit of information I want to comment about is the fact that even though applications running under XP mode appear seamlessly alongside Windows 7 applications, they are still running on a virtual machine. From what I’ve seen the boundary is not noticeable to the end user - the application’s shortcuts appear in Windows 7’s start menu, the tray icons appear in Windows 7’s tray, etc. But apps in XP Mode run completely separate from their Win7 counterparts, and the VM itself needs to be patched with its own version of Windows Update, requires specific policies applied to it, etc. It goes without saying that all this adds overhead to managing these type of deployments, and may cause incompatibilities if an app requires interaction with other programs installed on the Windows 7 side (VB6 apps using Office’s COM API is a common example – will you require separate versions of Office, one in the XPVM, and another one on W7 for daily use?).
• Finally, XP Mode uses Terminal Services and something similar to the RemoteApp mechanism to display applications on the Windows 7 desktop (not sure how other VMMs such as Parallels’ Coherence manage it) . Even though the integration is almost seamless, there are a few quirks here and there that make for an inconsistent experience (drag and drop files, etc), and may affect the performance and L&F of the application.

This post argues that the best solution would be to use Microsoft’s App-V technology to virtualize “XP and older” applications. I agree that would be an ideal solution. But maybe there is a reason why it works like it does – so that you won’t get too comfortable. XPM, IMHO, should be considered as an intermediate step towards moving your legacy apps to the latest technologies.

(As a side note, remember I did a lot of work on Virtualization, and think it is a good way to get the most out of your IT infrastructure resources. XPM, to me, is an excellent idea to start dropping all the legacy parts of Windows without compromising application compatibility, and a smart move at that. )

As you are probably well aware, along with the release of Windows 7 RC came some big news that affect Visual Basic 6.0 applications: Professional and Ultimate Editions of Windows 7 will feature a Windows XP Mode for backwards compatibility with legacy applications. This means that even if you are using components that have issues with Windows 7, you will be able to run your VB6.0 application on the new operating system, albeit within a Windows XP virtual machine.

It is important to mention that the VB team over at Microsoft was already making sure the IDE and VB6 runtime would work on Windows 7, as I commented before (second comment on that post) based on the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7:

The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on Windows Vista, Windows Server 2008 and Windows 7.
The Visual Basic team’s goal is that Visual Basic 6.0 applications that run on Windows XP will also run on Windows Vista, Windows Server 2008 and Windows 7. The Visual Basic team is also committed to the Visual Basic 6.0 development environment running on Windows Vista, Windows Server 2008 and Windows 7.

The objective of XP Mode is clearly to move forward the Windows architecture to the latest technologies, free of all the legacy bits required to maintain compatibility of old applications (read the History posts at the The Old New Thing blog for examples), while at the same time it allows developers to smoothly upgrade their applications without the threat of the application not working in the new OS. It is basically a compromise of old vs. new. And it is very easy to draw parallels between XP Mode and the approach taken by Apple, first with Classic and then with Rosetta, to smooth the transition to new platforms. But as was the case in those scenarios, Classic was eventually phased out, and Rosetta will eventually be as well.

I personally think that this technology may end up being around for a while, and may even end up included in the next versions of Windows if there is enough customer demand for it. This has to be the same technology used in their Microsoft Enterprise Desktop Virtualization (MED-V) solution, targeted towards enterprise customers:

“Microsoft Enterprise Desktop Virtualization (MED-V) provides deployment and management of virtual Windows desktops to enable key enterprise scenarios. MED-V 1.0 helps enterprises upgrade to the latest version of Windows even when some applications are not yet compatible.”

Even in the scenario that XP Mode is supported for a long time, you still have to consider it as something that can be used for a smooth transition while you upgrade your applications to the .NET Framework, and not as an excuse for not upgrading. It can help you plan a gradual migration, were you first start migrating certain modules while leaving others in VB6, with tools like the Interop Forms Toolkit. And keep in mind that even though the application will run, the IDE is simply not supported anymore and neither are most controls that cause compatibility issues. And at the same time you will be missing the benefits of using the latest technologies and the increased productivity of the .NET Framework.

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.