Visual Basic Upgrade Companion 2.0 - The tool you have been waiting for

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!

So Long VB6, and Thanks for all the Fish

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!!

Useful MSBuild Custom Tasks

I present here the implementation of some useful tasks
In Artinsoft we perform massive migrations of VB6 code to VB.Net
and C#.

And sometimes after migration there are customizations to be
performed on the code, to add new functionality or to set certain new
properties.

 The idea was to provide a couple of very simple and puntual MSBuildTask
 to illustrate how easy it is to create custom tasks and to provide a starting
 point to create new one.

 You can freely use this code, just keep this comments and remember this is just
 a sample code. There are not warranties. ;) And i made it a rush I know it could have
 been written better

 Artinsoft
 mrojas@artinsoft.com
 

The implemented tasks are:

RemoveCOMReference 

FixOutputPath 

The following is a sample project file

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- make sure that the Assembly is in a place where msbuild can find it, a simple way is just to put it 

in the same directory of your .proj file -->

<UsingTask TaskName="SomeUsefulTasks.MSBuild.RemoveCOMReference"    
  AssemblyFile="SomeUsefulTasks.dll"/> 

<UsingTask TaskName="SomeUsefulTasks.MSBuild.FixOutputPath"         
  AssemblyFile="SomeUsefulTasks.dll"/> 

<UsingTask TaskName="SomeUsefulTasks.MSBuild.AddProjectReference"   
  AssemblyFile="SomeUsefulTasks.dll"/> 

<UsingTask TaskName="SomeUsefulTasks.MSBuild.AddSimpleReference"    
  AssemblyFile="SomeUsefulTasks.dll"/> 

<UsingTask TaskName="SomeUsefulTasks.MSBuild.ChangeProjectBuildSetting"    
  AssemblyFile="SomeUsefulTasks.dll"/> 

   <ItemGroup>

    <VSProjects Include="$(Start)\**\*.*proj" />

  </ItemGroup>

<!--

Run with 
MSBUILD SampleProject.proj /target:COMReference /p:Start="C:\MyCode"

-->

  <Target Name="COMReference">

    <RemoveCOMReference SourceFiles="@(VSProjects)" ComReferenceName="MSXML2" />

  </Target> 

<!-- 

Adds a project reference  

Run with 

MSBUILD SampleProject.proj /target:AddProjectReference /p:Start="C:\MyCode" /p:ProjectPath="C:\MyCode\MyNewSuperProject\Project1.csproj"

-->

   <Target Name="AddProjectReference">

      <AddProjectReference SourceFiles="@(VSProjects)"  AbsolutePathToProject="$(ProjectPath)"/>

   </Target> 

<!-- 
Adds a reference to a standard assembly 

Run with 

MSBUILD SampleProject.proj /target:AddSimpleReference /p:Start="C:\MyCode" /p:Reference="System.EnterpriseServices"   

-->

<Target Name="AddSimpleReference">

      <AddSimpleReference SourceFiles="@(VSProjects)" Reference="$(Reference)" />

</Target> 

<!-- 
Resets the OutputPaths to .\bin\Debug and .\bin\Release 

Run with 

MSBUILD SampleProject.proj /target:FixOutput /p:Start="C:\MyCode" /p:Reference="System.EnterpriseServices"   

-->

<Target Name="FixOutput">

    <FixOutputPath SourceFiles="@(VSProjects)"  />

</Target> 

<!-- 

Adds a reference to a standard assembly 

There are several options here for example to set the project debug info to pdb-only do this:

Run with 

MSBUILD SampleProject.proj /target:ChangeSettingToPDBOnly /p:Start="C:\MyCode" 

Or run with 

MSBUILD SampleProject.proj /target:ChangeSettingAddAConstant /p:Start="C:\MyCode" 

Or run with 

MSBUILD SampleProject.proj /target:SettingComInterop /p:Start="C:\MyCode" 

-->

<Target Name="ChangeSettingToPDBOnly">

      <ChangeProjectBuildSetting 

          SourceFiles="@(VSProjects)" 

          ConfigurationType="All" 

          Setting="DebugType" 

          NewValue="pdbonly" />

</Target> 

<Target Name="ChangeSettingAddAConstant">

      <ChangeProjectBuildSetting 

          SourceFiles="@(VSProjects)" 

          ConfigurationType="All" 

          Setting="DefineConstants" 

          NewValue="MYNEWVAL" 

          Add="True"/>

</Target> 

<Target Name="SettingComInterop">

      <ChangeProjectBuildSetting 

          SourceFiles="@(VSProjects)" 

          ConfigurationType="All" 

          Setting="RegisterForComInterop" 

         NewValue="true" />

</Target> 

</Project>

DOWNLOAD CODE AND BINARIES

Get Relative Path

I had the requirement of creating a MSBuild custom task that opens a .csproj
adds a reference to another project.

The problem I faced is that references in VisualStudio are generated as relative paths,
so I needed something to help me generate relative paths.

After some Googleing I finally found this code. It was in a long forum discussion
and was posted by a guy named something like Marcin Grzabski. And here it is for posterity.

        private static string EvaluateRelativePath(string mainDirPath, string absoluteFilePath)

        {

            string[]

            firstPathParts = 

             mainDirPath.Trim(Path.DirectorySeparatorChar).Split(Path.DirectorySeparatorChar);

            string[]

            secondPathParts = 

             absoluteFilePath.Trim(Path.DirectorySeparatorChar).Split(Path.DirectorySeparatorChar);

            int sameCounter = 0;

            for (int i = 0; i < Math.Min(firstPathParts.Length,secondPathParts.Length); i++)

            {

                if (

                !firstPathParts[i].ToLower().Equals(secondPathParts[i].ToLower()))

                {

                    break;

                }

                sameCounter++;

            }

            if (sameCounter == 0)

            {

                return absoluteFilePath;

            }

            string newPath = String.Empty;

            for (int i = sameCounter; i < firstPathParts.Length; i++)

            {

                if (i > sameCounter)

                {

                    newPath += Path.DirectorySeparatorChar;

                }

                newPath += "..";

            }

            if (newPath.Length == 0)

            {

                newPath = ".";

            }

            for (int i = sameCounter; i < secondPathParts.Length; i++)

            {

                newPath += Path.DirectorySeparatorChar;

                newPath += secondPathParts[i];

            }

            return newPath;

        }

And to use is just do somelines like:

            String test = EvaluateRelativePath(@"E:\Source_Code\Code\ProjectsGroup1\Project1", @"E:\Source_Code\Code\ProjecstGroup2\Project2");

//This will genearate something like ..\..\ProjectGroup2\Project2

VB6 is dead. Long live .NET

Well, not exactly. But official support for Visual Basic 6.0 has certainly ended, as I’ve mentioned on previous posts. VB 6 has been used by millions of people all over the world to develop applications ranging from thousands to millions of lines of code. It’s definitely time to move those significant organizational investments to .NET, and appropriately ArtinSoft is about to launch a new enhanced version of its VB to .NET migration product (Visual Basic Upgrade Companion). Stay tuned for details…

Jay Roxe on VB to .NET migration motivations and benefits

Browsing through some of the good old VB to .NET migration resources I’ve accumulated through all these years, I rediscovered a Dr. Dobb’s interview by Scott Swigart with Jay Roxe. Among other things, they talked about the motivations for migrating from Visual Basic 6.0 to the .NET platform, either to VB.NET or C#, and some of the benefits of the new environment.

Putting aside the VB6 support end concerns, he describes the lifecycle of any application as one of the motivations for a .NET upgrade: “The application has reached a point where the code has grown beyond its original scope, and it's time to rewrite the application anyways, and it just makes sense to transition to the latest development platform at the same time”. Other incentives relate directly to the .NET Framework’s new functionality and development capabilities, and that’s where the benefits come under the spotlight. For instance, he mentions that “We're also seeing, particularly for some of our Web customers, that when they took a VB6/ASP application, and moved it to a VB.NET/ASP.NET application, it was 300 percent more scalable, and they got 200 percent more throughput from the application”.

Roxe also explains how the ClickOnce technology solves the DLL Hell issue by providing better deployment and management, checking the prerequisites availability before installing the application itself, with the option of setting up version checking and without impact to any other applications on the machine. There’s also the possibility of deploying a COM component with an application without having to register it, allowing multiple side-by-side installations of that component without conflicts.

Finally, he responds to the questions around choosing the programming language (VB.NET or C#) once you decide to move to the .NET platform, adding some advice around VB to .NET migrations and pointing some of the available resources. You can read the whole article here, and if you have a VB to .NET migration project in your hands or want to share any experience you’ve had with such upgrades, I’d definitely love to hear about it.

Upcoming VB Webcasts

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.

Pretty Printers / Format Code / for C# VB.NET

In my past life I spent a few eons writing Java code. And it wasn't bad. We had nice tools like Jalopy! that allowed us to have
code in a very standard way.

And I missed that. I've been looking around for something similar but I havent found anything like that :(

Until I found a great post from Chris Eargle, he improved the original solution from Kelvinpinch

Well here's the code.

Public Sub FormatSolution()
     Dim sol As Solution = DTE.Solution
     For i As Integer = 1 To sol.Projects.Count
          FormatProject(sol.Projects.Item(i))
     Next
End Sub 

Private Sub FormatProject(ByVal proj as Project)

     For i As Integer = 1 To proj.ProjectItems.Count
          FormatProjectItem(proj.ProjectItems.Item(i))
     Next
End Sub

Private Sub FormatProjectItem(ByVal projectItem As ProjectItem)

     If projectItem.Kind = Constants.vsProjectItemKindPhysicalFile Then

          If projectItem.Name.LastIndexOf(".cs") = projectItem.Name.Length - 3 Then
               Dim window As Window = projectItem.Open(Constants.vsViewKindCode)
               window.Activate()
               projectItem.Document.DTE.ExecuteCommand("Edit.FormatDocument")
               window.Close(vsSaveChanges.vsSaveChangesYes)
          End If
     End If

'Be sure to format all of the ProjectItems.
     If Not projectItem.ProjectItems Is Nothing Then
          For i As Integer = 1 To projectItem.ProjectItems.Count
               FormatProjectItem(projectItem.ProjectItems.Item(i))
          Next
     End If

'Format the SubProject if it exists.

     If Not projectItem.SubProject Is Nothing Then
          FormatProject(projectItem.SubProject)
     End If
End Sub

To use it perform the following steps:

•  Go to the VS IDE Tools Option
  
• Then Select the Macros option and select Macros IDE...
  
• This will open the macros IDE
  
• In the Macros IDE navigate to the Module1, and Insert the code
  

To run the Macro go to Tools\Macros\Macro Explorer

And select FormatAll :)

And last but not least if you want to runit from the command line just do:

devenv /command "Macros.MyMacros.Module1.FormalAll" MyProject.csproj or

devenv /command "Macros.MyMacros.Module1.FormalAll" MySol.sln or

Upgrade a VB6 Application Incrementally: The Interop Forms Toolkit

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. :)

Killing open Terminal Services sessions remotely

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.

Windows Server 2008 released

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.

ActiveX exceptions when running in .NET

During migration to C# or .NET it is easier to keep the same ActiveX.
The VBCompanion does a great work in migrating the ActiveX control using the .NET ActiveX wrappings and fixing all method calls. 
Sadly sometimes those ActiveX do not work properly in .NET.

Well we have good news.
Recently my friend Jose David (who we keep bothering because he is now 
a Project Manager and now he only programs in MS Excel and MS Project, I added the MS by his request :P) fixed a curious bug
we had with an aplication we migrated from VB6 to C#.

The thing is that the aplication had an ActiveX control with a strange runtime behaviour.
We migrated the application keeping the ActiveX control and in most ocasions it worked ok.

But randomly it started throwing exceptions.

During the testing he discovered that if he repeated the steps slowly the bug did not reproduced.

So his idea was that it was due a garbage collection issue. And SURPRINSINLY he was right :P

He added this:

System.GC.Collect();

System.

GC.WaitForPendingFinalizers();

 And the application started to work.

It seems like some of the COM objects needed a little more time for releasing all references :)

IsMissing migration in VB.NET or C#

Recently  we added some support for migrating the IsMissing function to VB.NEt or C#

The thing is. In VB6 the IsMissing Function is TRUE only if you have something like:

Public Sub Foo(Optional str)

Where you dont specify the variable type, or if you have

Public Sub Foo(Optional str as Variant)

And is IsMissing is FALSE for any other case. Including Optional variables whose definition type is not Variant.

So let's see some examples to illustrate the idea:
 Example 1:

Public Sub Foo(str, a As Integer, b As Integer, Optional c As Integer)
    MsgBox (str & "Foo Is missing a " & IsMissing(a))
    MsgBox (str & "Foo Is missing b " & IsMissing(b))
    MsgBox (str & "Foo Is missing c " & IsMissing(c))
End Sub

It occurs that IsMissing is really FALSE in all cases. So it is equivalent to:

Public Sub Foo(str, a As Integer, b As Integer, Optional c As Integer)
    MsgBox (str & "Foo Is missing a " & false)
    MsgBox (str & "Foo Is missing b " & false)
    MsgBox (str & "Foo Is missing c " & false)
End Sub

Example 2:

Public Sub Goo(str, a As Integer, b As Integer, Optional c As Object, Optional d As Byte, Optional e)
    MsgBox (str & "Goo Is missing a" & IsMissing(a))
    MsgBox (str & "Goo Is missing b" & IsMissing(b))
    MsgBox (str & "Goo Is missing c" & IsMissing(c))
    MsgBox (str & "Goo Is missing d" & IsMissing(d))
    MsgBox (str & "Goo Is missing e" & IsMissing(e))
End Sub

All cases EXCEPT "e" are equivalent to FALSE

Public Sub Goo(str, a As Integer, b As Integer, Optional c As Object, Optional d As Byte, Optional e)
    MsgBox (str & "Goo Is missing a" & false)
    MsgBox (str & "Goo Is missing b" & false)
    MsgBox (str & "Goo Is missing c" &false)
    MsgBox (str & "Goo Is missing d" & false)
    MsgBox (str & "Goo Is missing e" & IsMissing(e))
End Sub

So if you are migrating your VB6 Code to C# put attention to these little details it can save you a lot of time.And remember that this is just one feature of VBCompanion tool ;)

Internet Explorer Runtime Error Do you Wish to Debug?

Hi, for several months I lived with an extremely unconfortable bug.
On some pages IE will display an alert dialog indicating 

Error
A Runtime Error has occurred.
Do you wish to Debug?
Line: blablabla
Error: blablalba

 Well finally I looked in google and found this: http://support.microsoft.com/kb/822521

So if anybody had to live with this bug like me, I hope this helps him

Here is a valuable comment I received. So I'm adding it so it will help somebody else.

I was plagued by the "Runtime error - do you wish to debug?" problem for months
and finally resolved it last night, after testing everything else in the MS knowledgebase
to no avail (http://support.microsoft.com/kb/308260/ln/).
The problem disappeared instantly after a tip-off elsewhere to install & run SpyBot. (Looks like my SpywareBlaster 4.1 failed me there.)
So it wasn't:
my IE 7 settings (Disable script debugging),
operating system (XP Pro SP3),
firewall (Comodo Pro),
antivirus (Avast!) or
scripting engine (WindowsScript 5.7) - just Spyware

Opening Projects Migrated with the VB Upgrade Companion on Visual Studio 2008

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.

Countdown to Extinction

 .... 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.

The curtain unveils – Aggiorno is out!

Since 2007, a team of ArtinSoft’s experts has been working on a tool that helps automate a lot of actions commonly performed by web developers, increasing their productivity and resulting in more efficient pages. The outcome is Aggiorno, an expandable plug-in for Visual Studio that produces SEO friendly, XHTML compliant, CSS styled HTML and ASP.NET, which eases enormously the task of delivering web standards compliant web sites. Based on a unique pattern detection and transformation engine, Aggiorno’s beta version is currently available on a by-invitation-only basis, so register now and get early access to this revolutionary product!

Aggiorno is coming out of stealth mode: www.aggiorno.com

Happy 2008!

During last year, ArtinSoft has also been working on a new product that we called Aggiorno ( www.aggiorno.com ).  Aggiorno is a Visual Studio add-in designed to increase the productivity of web developers.  Aggiorno helps developers with a broad range of topics like web standards, SEO (Search Engine Optimization), Accessibility, XHTML, ASP.NET, etc.

If you want to know more about aggiorno you can visit our new web site or the official blog: www.aggiorno.com\blog .

 In this blog, I will continue to discuss Visual Basic Upgrades and its implications.  By the way, customers are increasingly getting more excited about the speed and safety of migrations vs rewrites.

Visual Basic 6.0 - End of Life is near!

There has been a lot of controversy around the end of Visual Basic 6.0, a language that was generally available since January 1999. Opposition is comprehensible when you take into account that there is a huge VB 6.0 code base out there. But when you look at Microsoft's Product Family Life-Cycle Guidelines for Visual Basic 6.0, it is ultimately a very large orphaned code base.

On previous posts, I've mentioned the End Of Life of VB6, referring specifically to the official support phase. Microsoft's Visual Basic 6.0 support policy has been in effect since the release of Visual Studio .NET. The Mainstream Phase, where standard support offerings were available (professional telephone and online incident support, free critical updates and free online self-help tools), ended on March 31, 2005. The Extended Phase began in April 2005 and will end on March 2008. During this period, that is, at this moment and for the next couple of months, standard support offerings are still available, including Premier Support, paid telephone and online incident support, and free online self-help tools. Free telephone and online incident support is no longer being provided, and critical updates are available for a fee.

Starting on April 2008, Visual Basic 6.0 will enter the Non-Supported Phase, where support will no longer be offered by Microsoft. The Visual Basic 6.0 family of products includes the Standard, Professional, and Enterprise editions of Visual Basic 6.0. It also includes users of Visual Basic 6.0 who obtained their licenses via Visual Studio 6.0 Professional and Enterprise editions.

Of course, you may be able to find support elsewhere; with such a large code base, the community is a viable source for support. There is a lot of self-help tools and content out there: articles, how-to guides, troubleshooting information, frequently asked question lists, webcasts, and more. But this might not be enough for companies with business critical applications and/or subject to regulations, or ISVs whose customers will demand the latest technologies without doubt.

End of support doesn't imply that you can't continue using the product; it doesn't mean that the IDE will stop working, but it signifies that any existing or new defects are unlikely to ever be fixed. You will not find any new Service Packs, which keeps your product up-to-date with the latest collection of fixes for the core product and components, since Microsoft stopped delivering these after the Mainstream Support Phase. Finally, in the Non-Supported Phase, no security fixes will be provided at all.

In the end, all this is only natural. There have always been advances in software development capabilities, and the history of Microsoft's Visual Basic has been no different. For example, for VB4 Microsoft introduced 32-bit address spaces. But in going from VB6 to VB .NET Microsoft did far more than that. It re-wrote the whole product: VB.NET is, in essence, a totally new programming language. It bears some superficial resemblance to VB6, but underneath it is entirely predicated on the .NET Common Language Runtime (CLR) and its data types; and at compile time, you have to use the .NET framework. Visual Basic .NET is clearly a better language, with its improved error handling and a much better development tool in Visual Studio. It's also multithreaded and a true object-oriented programming language, which limits backward compatibility.

Software assets represent a competitive advantage, and keeping up to date with the latest technologies is crucial in today's business environment. Precisely, Microsoft disclosed those guidelines to provide the advanced notice required by many to make accurate information-technology and product planning decisions within their organizations. So this is the time to stop developing legacy applications in VB6 and assess the remaining VB portfolio for modernization options. It might not be a trivial task, but there are VB to .NET migration products and services that can definitely ease the process.

Happy new year!