One of the nicest features of the Visual Basic Upgrade Companion version 2.0 is the support for Migration Profiles. These profiles give you control over which translations to use for a particular migration, improving the quality of the generated code and applying only the conversions desired (for example, for specific third party components). Profiles are managed through the Profile Maintenance screen, as shown here:

If look at the screen in some detail, you will see some of the features included with the tool. Here you can select, for example, to convert the MAPI (Mail API) library to the Microsoft.Office.Interop.Outlook component. And it shows that this particular conversion has a coverage of 80%. This particular library shows why Migration Profiles are important. If the application you are migrating is an end-user application that is locally installed in the user's desktop inside your enterprise, and MS Outlook is part of your standard installation on these desktops, then it should save you quite a bit of work to let the VBUC perform this transformation. If, however, it is a server-side application where MS Office is very rarely installed, then having this option selected will only cause you additional work later on, as you will have to go through the code and remove the references.

Other good examples are the ADODB and ADOCOMMON plug-ins. Both of them convert code that uses ADO into ADO.NET. How they do it, however, is completely different. The first plug-in, ADODB, converts ADO into ADO.NET using the SqlClient libraries, so it only works with SQL Server. The ADOCOMMON plug-in, however, generates code that uses the interfaces introduced with version 2.0 of the .NET Framework in the System.Data.Common namespace. This allows the application to connect to any database using an ADO.NET data provider that complies with this interfaces - most major database vendors now have providers that meet that specification. So you can use either transformation depending on your target database!

The previous two examples illustrate the importance of Migration Profiles. As you can see in the screenshot above, the tool currently has a large amount of plug-in with specific transformations. This number is expected to grow over time. I will be covering some of these plug-ins in later posts. Stay tuned!

I was expecting the annoucement near the end of the week, but here it is - The Visual Basic Upgrade Companion version 2.0 was released today! Just in time to attend that other tool's funeral ;)

I am still waiting for the official press release, but at least the press here in Costa Rica is already talking about it (link in spanish). So you know, the VBUC2.0 is a considerable improvement over previous versions of the Companion. Some of the most interesting new features are:

• Solves over 800 issues reported by our consulting staff, testing team, partners and end-users.
• Significantly reduces the amount of manual work required to compile the migrated application, so you can start the testing earlier in the migration process
• Improves the quality of the migrated code
• Adds the concept of Migration Profiles - you can select from a series of migration features and apply only those that you want to a particular migration. This greatly improves both the quality of the migrated code, and decreases the amount of manual work required after the migration. It also allows greater future expandability of the product.

As you probably know, eye candy sells. And it makes your life easier, too. So the VBUC2.0 includes a new Graphical User Interface called the Upgrade Manager, that incorporates all the features and concepts described above into one easy to use environment:

If you have been thinking about upgrading your VB6 applications to the .NET framework, think no more. With this new version of the VBUC you will be able to have your .NET application up and running in no time!

I may be a little late to the obituary, but VB6 support is finally, officially, irrefutably gone. The IDE, as stated in Microsoft's Product Life-Cycle guidelines, "... will no longer be supported starting March 2008". Even though VB6 (or Basic for that matter) didn't enjoy the best reputation as a programming language (best illustrated by the famous Edsger W. Dijkstra quote), you can't deny the huge influence it's had over the past 15 years. The easy-to-use paradigm followed by VB IDEs lent itself to be used by both amateur programmers, that caused many headaches during the years, and professional developers that were really able to harness the power and ease of use to create impressively robust solutions that are still running to this day.

So if you are thinking of moving away form VB6, obviously I'm going to steer you in the direction of the Visual Basic Upgrade Companion.  There is, however, another reason for this as well... pretty soon we are going to release a completely updated version 2.0 of the tool, which has some very interesting new features and does an incredible job of converting your VB6 code into the .NET language. Watch this space, as I will be writing about this new version soon!!

A quick post to let you all know that Beth Massi, Program Manager on the Visual Studio Community Team, will be doing a series of webcasts on Visual Basic 9. They will be mostly about the new features of VB9, including one about LINQ in VB that I am particularly interested in. Another one of them deals specifically with Visual Basic 6.0 to .NET migrations, called Live From Redmond: Migrating Your Visual Basic 6 Investments to .NET. If you haven't yet considered moving your VB6 application to the .NET Framework, this may be a good place to start. Remember that the end is near....

For more information on the webcasts, check out this post over at Beth's Blog.

In some migration projects you have to take an incremental approach. You just can't disappear with an application for a few months, and then come back with the application in the target language. Because of this, when we do migration projects, we try to divide the project in smaller milestones, so that developers can continue working on a certain module of the application, while another group migrates a different module.

It turns out that is you are migrating from Visual Basic 6.0 to the .NET Framework (using either Visual Basic.NET or C#), you can do even smaller steps. Microsoft offers the Microsoft Interop Forms Toolkit, a set of tools that you can use to run .NET forms and controls in VB6 applications. This Toolkit allows you to create an even less disruptive migration strategy, by creating an incremental upgrade process in which you can start out by moving some controls first, then some forms, and, before you know it, you'll have your applications running completely in .NET.

I realize this has been out for a while, but it is still worth mentioning, since there's tons of people out there that haven't moved from VB6 yet. This may give all of you some incentive to at least get started with the first incremental steps. :)

This tip isn't really migration-related, but I've used it so many times these past few days that I think it is worth sharing. We work with virtual machines A LOT, using Virtual Server 2005 R2 SP1. Every once in a while you need to log into a server using Terminal Services to delete old VHDs to make room for a new one, opr just for any other miscelaneous task that can't be done through the web administration client. And, unfortunately, sometimes there are two terminal services sessions open already, so you get the following error:

"Terminal server has exceeded maximum number of allowed connection"

You then stare at your monitor in frustration for a few seconds. After that, you figure out who the culprit is and ask him politely to "PLEASE LOG OFF".

Well, after discovering this tip, there is no longer a need to stare at your monitor or to ruin your relationship with your coworkers. Turns out there are a couple of command line tools you can use to close remote Terminal Services sessions. They are available in both Windows XP and 2003. The first one, qwinsta, lists all the open sessions on a particular server:

 c:\>qwinsta /server:192.168.123.123
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd
                   jpena                     1  Disc    rdpwd
                   administrator             3  Disc    rdpwd

In this case, you can see that Juan Peña (user jpena) has an open session in the disconnected state. In order to close his session, you need to use the second tool, rwinsta:

rwinsta /server:12.12.12.12 3

This command will kill the session with ID 3 (jpena's). And voilà! After this, I'm able to connect to the server. :-)

Credit goes to Scott Forsyth's WebLog.

A quick post to tell everyone that the day finally came: Windows Server 2008 was released today. You can find more information about it on the Windows Server 2008 page, and watch the keynote here.

The biggest deal, from my perspective, is Hyper-V. This will have a significant impact on the IT market, by exposing thousands of IT profesionals to a hipervisor-based virtualization solution. Another very interesting technology is RemoteApp, which allows you to use, through Terminal Services, just one application instead of the complete desktop. It solves a deployment issue that required expensive software solutions in the past - and something we run into every once in a while when determining the best deployment strategy for migrated Informix 4GL applications.

Now that Visual Studio 2008 is available, you might wonder what will happen with the Visual Studio 2005 projects generated with the current version of the VB Upgrade Companion (VBUC). For starters, it is worth mentioning that Visual Studio 2008 fully supports projects created in the .NET Framework 2.0, like the ones generated with the VBUC. The newer version of the .NET Framework (3.0, shipped with Vista, and 3.5, shipped with VS2008) keep the same core version of the CLR (2.0) as before, with very few minor changes. There are no compatibility or breaking changes like when upgrading from versions 1.1 to 2.0 of the .NET Framework.

When you open a VS2005 project in VS2008, you are greeted with the new Visual Studio Conversion Wizard:

Once you click Next, you can select whether to create a backup of the project or not. I chose to NOT create a backup, since this is a copy of the project, since I will be comparing both .csproj files later on. Press Next.

The next step tells you what will happen during the conversion:

Press Finish, and after a little while, the process will be complete:

You can check out the Conversion Report afterwards. For most projects, however, the reports should be in blank:

So there you have it. After converting this test VS2005 Windows Form application, I was able to continue working on it without any issues. It is true that the code generated by the VBUC will not take advantage of all the neat features of the .NET Framework 3.5, such as WPF, but you should be able to continue working with the migrated code after moving to Visual Studio 2008 without any problems.

 .... and so we reached 2008. This may seem like any other "average" year - the price of gas keeps going up, everybody talks about global warming, and will be an election year in the US (so we have one more reason to stop watching TV). However, for a large group of IT departments around the world, 2008 is a BIG year. 2008 is the year when Microsoft officially kills support for Visual Basic 6.0.

It took a while, but as in Chronicle of a Death Foretold, everybody knew it was coming. Microsoft's Product Family Life-Cycle Guidelines for Visual Basic 6.0 details the different support stages VB has gone through:

...
Mainstream Phase
The Mainstream phase will be in effect for six years after the product's general availability date. Visual Basic 6.0 was generally available in January 1999. Mainstream support will end March 31, 2005.

Extended Phase
The Extended phase will be in effect from seven to nine years after the product's general availability date. Extended Phase support begins in April 2005 and ends March 2008.

Non-Supported Phase
Visual Basic 6.0 will no longer be supported starting March 2008.

If you are still using Visual Basic 6.0, however, there is no need to despair. According to the Support Statement for Visual Basic 6.0 on Windows Vista, the VB6 runtime will be supported in Vista for at least 10 more years (5 of mainstream support + 5 of extended support). The IDE, however, will be unsupported from April 8, 2008. And you will be missing all the new technology shipping with the .NET development tools - web services, WPF, managed code, etc. There is, however, an easier way to move away from VB6 quickly...

You can use the Visual Basic Upgrade Companion to move your application quickly and effectively from VB6 to either Visual Basic .NET or C#. Our experience in migration projects shows that by using the VBUC, you can drastically reduce the time it takes to move your application to the .NET Framework, reducing the risk vs. a complete rewrite, and keeping all your business rules, but in a modern platform that will allow you to use the latest technologies moving forward.

You can find more information on the Visual Basic Upgrade Companion here.

For those of you who missed it, Windows Server 2008 RC1 was released yesterday, with the Beta of Hyper-V. Finally!

You can download it here, and there is some more information on the Virtual PC Guy's WebLog.

Even though most of our clients are from the US and Europe, lately we have been getting more and more projects in Latin America, specially in Mexico. You’ve probably heard about a large project we started in Mexico recently. We also signed two smaller projects in the last month, and last week I was on-site at a customer in Mexico D.F. working on yet another one.

The thing is that in Mexico, even though still in Latin America (remember that we are based in Costa Rica), there were a couple of cultural differences that really caught my attention.

First of, the schedule. We in Costa Rica usually have lunch between 12 and 1. In Mexico it is usually between 3–4pm, 3–5pm or 2–4pm, depending on the company. That is a bit late for us… let’s just say that by 3pm I was starving.

The second one was the dress code. Normally in Europe and in the US, IT departments are very laid back, and have a very lax dress code. Through out Latin America, however, it is mostly suit and tie. Only in a few places can you show up with “business casual” or even “casual” clothes. This is changing, though, and going more and more casual.

All in all, going to Mexico was a nice experience. The people I worked with were really nice, and treated me well (other than keeping me hungry until the mid-afternoon  ). I hope we sign this project, so I’ll be able to go back!

Some time ago I was interviewed (via email) by El Financiero, a weekly business-oriented newspaper from Costa Rica, regarding 64–bit technologies. A small quote from the interview was published a couple of weeks ago, along with some information I gave them on the advantages of moving to 64–bits.

The technical journalist from the newspaper did an article on how the Costa Rican Central Bank, BCCR, is moving their payments system (SINPE) from 32–bit to 64–bit servers, and the benefits they are getting from the move. These benefits include enhanced speed and database performance, given the large memory capacity of the new architecture. This is a fairly large system that handles over 3 million financial transactions per month.

ArtinSoft had some involvement in moving this system from Visual Basic 6.0 to Visual Basic .NET some time ago, in the dawn of the .NET era. There is even a published case study on the system – you can find it here.

Their plan currently is to slowly move all their systems to 64–bit over a period of 2 years.

You can check out the article here:  BCCR ajustó tecnologías (you may need to be registered with the site).

A large percentage of the work I do here at ArtinSoft is related to what we call  Ready programs. The Ready program is part of the Ready-Set-Go methodology – a migration project methodology developed here at ArtinSoft that has given us great results.

The Ready assessment program, or Ready, is the first stage of this methodology. As you are probably aware, the more planning you put into a project, the higher the probability that the project will be succesful. Well, with the Ready, we do a an in-depth analysis of the project before we start, and come up with a detailed project plan that takes into account any risks and possible issues with the migration.

The first step in a Ready is a thorough assessment of the size, complexity, migration goals, and testing procedures for your current application. This step involves a 5– to 10– day on-site analysis of an application. During that week(s), we perform interviews with the development, PM and testing teams, to get a feel for the project and gather enough information to proceed with the project. Once we come back to our office, we work alongside the development team to create an accurate estimate of the effort required to perform the migration.  This normally includes any customization of the migration tools necessary to minimize the manual effort in the project.

The final product of the Ready program is a detailed written report that includes a fixed-cost proposal for completing the migration. This is usually delivered two or three weeks after the on-site visit. This report, on its own, has tremendous value for the organization. It summarizes the requirements for the migration, and the issues that need to be addressed even if the project is not performed by ArtinSoft. It can also help in justifying the need to modernize outdated applications.

The Ready program is a low-cost, low-risk approach to getting detailed information on your migration project. For more information on the ready, and on the overall methodology, check out the Ready-Set-Go methodology page at ArtinSoft's website.

Ever since we started working on the Virtual Server seminars, we’ve been hearing about I/O Virtualization, and how it will improve the virtualization landscape as the VT instructions did. Well, today Intel unveiled its vPro platform, with this new technology.

 The technology is called Virtualization Technology for Directed I/O or VT-d. VT-d controls access from Virtual Machines to memory at the physical page level, preventing one VM from accessing other VM’s memory. This has the side effect of virtualizing interrupts and DMA tranfers, which in turn should increase the performance of virtual machines since the VMM would no longer need to trap and emulate the behavior from virtual machines.

For more information, check out or this article at Intel’s website, which contains a detailed explanation of the platform. For a more digested approach, check out this coverage at Arstechnica.

In case you missed it, Microsoft recently unveiled a new Virtualization Website. This website centralizes the information about all of Microsoft’s virtualization products.

I especially like the page about the different Virtualization Solutions offered by the company. It also caught my attention that they now have Softgrid application virtualization fully integrated with the virtualization stack.