ArtinSoft's Blogs

Software Migration Experts
Welcome to ArtinSoft's Blogs Sign in | Join | Help
in Search

Jose Aguilar's Blog

All things migrations, software and technology

June 2009 - Posts

  • Website Updates: More Information, Get a Quick Ballpark, Download a Trial and Buy a License Online

    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:

    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.

  • How to determine if a binary file has a dependency on the VB6.0 runtime

    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.

  • If the VB6.0 Runtime is supported in Windows 7, why should I move to .NET?

    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.

  • Show Migration Errors, Warnings and Issues (EWIs) on Visual Studio’s Task List

    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.

This Blog

Syndication

Powered by Community Server (Non-Commercial Edition), by Telligent Systems