All the white papers in one place

clock February 22, 2009 03:57

We just put online a new page that gathers all the whitepapers we have published so far, and the ones that will be in the future.

If you need guidance when selecting a conversion tool or a migration strategy, this is the place to go.

[NEW RELEASE] Version 1.10.03 is online

clock February 16, 2009 02:52

This new version differs from previous 1.10.02 only for the release number, yet several important new features have been added.

First , the new ThreadSafe pragma allows VB Migration Partner to generate .NET DLLs that are ready for multi-threading environments, such as DLLs meant to be used by ASP.NET clients. You can read more about this topic in a previous post and this KB article.Next, we have implemented a simple but effective mechanism for reducing startup time in complex N-tier applications consisting of dozens or hundreds DLLs. You can find more details here. Finally, we now provide a simple mechanism to let VB Migration Partner know whether a Variant variable is expected to contain a scalar value or an object. This information is used by VB Migration Partner to generate better code.

Registered users can download the new version using the command in the Help menu.

[WHITEPAPER] Tips for smooth migration of calls to Windows API methods

clock February 12, 2009 05:46

There many ways to skin a cat, as they say, and there are at least as many ways to convert a Windows API call from VB6 to VB.NET.

In general , you don't have to worryabout Declare statements and Windows API calls when migrating a VB6 project to VB.NET - if you are using VB Migration Partner, at least - because our tool can handle correctly even very contorted cases and can even fix a few subtle issues caused by peculiar .NET features like string immutability and orphaned delegates. However, at time you need to get your hands dirty and pay a lot of attention to API calls.

We have prepared a short but juicy technical whitepaper entitled Tips for smooth migration of calls to Windows API methods. Among the other things, this article shows how you can wrap API calls in methods and then replace these wrapper methods with calls to native .NET objects, so that in the end you have no dependencies on unmanaged code.

While speaking of API calls, here a few other articles that you might find useful:

[PRB] A call to a Windows API Declare returns a string filled with spaces
Calls to GetOpenFileName API method returns trimmed string
[INFO] Declare statements can generate methods with different names
[HOWTO] Migrate VB6 applications that use window subclassing
[PRB] VB6 applications that use window subclassing or other API callback methods throw a CallbackOnCollectedDelegate excetion 

Subtle threading issues and how to fix them (automatically) with VB Migration Partner

clock February 10, 2009 09:09

One customers brought an issue to our attention. He was using a migrated VB.NET component in a heavy multi-threaded environment (the component is called by ASP.NET pages) and found that occasionally the program crashed with an unexplainable error message. A quick look at the stack trace confirmed the initial suspect: the error was caused by two threads that initiates a call to the same method at the same time. We have fixed the problem in our library in a few minutes (the fix will appear in version 1.10.03, due in a few days), but we realized that the problem isn't confined to our library. To explain why, a short digression is in order.

VB6 components use Single-Threaded Apartment (STA) model: each thread lives in an “apartment” of its own. In plain English, this means that each thread works with a different set of global variables. For example, assume that the ActiveX DLL project contains a BAS module with the following variable declaration:

    ' ...(in the UserInfo.bas file)
    Public UserName As String

Thanks to STA threading model, each client – running in a different thread – can write this variable and read it back, without worrying about another client (in another thread) overwriting the variable with a different value. As you see, STA makes multi-threading programming virtually as easy as single-thread (i.e. traditional) programming. Of course,when writing multi-threaded apps you have to take care of many other potential concurrency issues – for example, two threads working on the same temporary file or registry key – but at least you don’t need to worry about global variables.

By contrast, components written in VB.NET – and all .NET languages, for that matter – use free-threading, which means that all threads can access all variables at the same time. Therefore, the VB.NET component exposes the same UserName field to all threads, which means that any thread can overwrite the value stored there by another thread.

To simplify programming in free-threaded contests, the .NET Framework supports the ThreadStatic attribute. You can apply this attribute only to static class fields – either fields defined in modules or fields defined in classes and marked with the Shared kewword:

    <ThreadStatic()> _
    Public UserName As String

All fields marked with the ThreadStatic attribute are stored in the Thread Local Storage (TLS) area. The separation among threads is automatic, because each thread owns a different TLS.

In theory, when migrating a VB6 DLL meant to be used by free-threaded clients, you should scrutinize each and every variable in BAS modules and decide whether to tag them with the ThreadStatic attribute. To make this task as easy as possible, as well as to avoid any manual edit of the resulting VB.NET code, starting with version 1.10.03 VB Migration Partner supports the ThreadSafe pragma, which can be applied at the project-, file-, method- and variable-level scope. In most cases, therefore, all you need to do is using a single pragma that affects all the variables in the current project:

    '## project:ThreadSafe True
    Public UserName As String

[WHITEPAPER] Comparing VB Migration Partner with other conversion tools

clock February 6, 2009 02:15

As I have written many times in this blog, we at Code Architects love competition. We think it's the driving force in any market, and software is arguably the field in which fair competion is likely to provide better results than anywhere else.

If users have more products to choose from, vendors are put under pressure and are more likely to improve their products at a faster pace. This is what we are seeing today in the segment niche of VB6 conversion tools, which has been quite still for years, until VB Migration Partner made its debut.

With more choices, however, developers face the difficult task of selecting the right tool for their needs. Basically, if you are planning to migrate your VB6 app to VB.NET you have three choices:

  • Microsoft Upgrade Wizard (that comes free with all versions of Visual Studio .NET)
  • Artinsof VB Upgrade Companion (an extension of Upgrade Wizard, with which it shares the same migration engine and approach)
  • Code Architects VB Migration Partner (by yours truly...)

To make an informed choice you have to compare these products, which isn't as easy as it sounds because there are so many factors to take into account. To help you in taking a decision, we prepared a feature comparison table that explains which features are fully (or partially) supported by each tool, and why you should care.

Rather than providing a dry list of feature names, we attempt to categorize each feature based on how it can affect the overall migration process. In the end, we came up with five categories:

C: the feature reduces or avoids compilation errors.

R: the feature avoids runtime errors and preserves functional equivalence.

M: the feature generates code that is more readable and concise, abides by .NET programming guidelines, and makes maintenance easier.

O: the feature generates optimized and faster VB.NET code.

T: the feature can reduce overall migration time and cost, for example it eliminates the need to prepare the VB6 app for the migration. Features that reduce learning and support costs also fall in this category.

Each feature can fall in just one category or in multiple categories. For example, the support for Gosub, On...Goto, and On...Gosub keywords clearly falls in category C, whereas the ability to generate correct cleanup code for IDisposable objects (e.g. database connections) belongs to category R (preserves functional equivalence, M (generated code follows .NET coding guidelines), and O (application that cleanup resources in an orderly manner are also more efficient).

We are aware that comparing our own VB Migration Partner with its competion is a delicate matter, therefore we tried to be as unbiased as possible. In building the feature list we used product information available at our competitors' Web site, therefore the result is as objective as it can possibly be.

When we couldn't find enough details on a given feature, we used a question mark (?) and added the suggestion to contact the vendor for more detailed info. It goes without saying that we will quickly revise the document if any reader deems that an item is incorrect or just misleading.

Happy comparison! Wink

[COMMENT] How to migrate 800,000 lines of code earlier than expected

clock February 1, 2009 05:51

More and more VB Migration Partner are finishing the migration of large business apps and are willing to share their experience with readers of this blog.

In 1995 we realized a client/server application in VB3 using several third party controls, such as Crystal Report, Formula 1, and Crescent QuickPak. Over the years the software was greatly enhanced with new features and was ported to VB5 and then to VB6.

Two years ago our customer asked us to port the application to .NET, which in the meantime had reached the remarkable size of 800,000 lines of code. A manual rewriting was clearly too complex and expensive.

Almost accidentally we learned about VB Migration Partner, which was in non-public alpha release at the time, and it already looked
quite promising for our purposes. We decided to invest some time in modernizing the VB6 code while waiting for the official release, which we adopted shortly after its official debut.

In these months we found the tool quite powerful and versatile, and surprisingly complete for a 1.0 release. More specifically, the included AxWrapperGen tool allowed us to create wrapper classes that guarantee the correct working of a few VB6 controls that aren’t directly supported under VB.NET. We estimate that this tool alone spared us several man months of hard work.

Finally, I’d like to thank Code Architects’ technical support team, who supported us through our endeavors, in a professional and efficient way. They and their software allowed us to complete the migration of our flagship application earlier than expected.

Marco Meneo
ProgeSoftware, Italy

800,000 lines of code is a *big* application to convert. Nevertheless, ProgeSoftware successfully completed the migration without any support from Code Architects other than the standard email support we offer to all our customers.

Unlike other conversion tools on the market, VB Migration Partner is so powerful and well documented that it requires no hiring external, expensive experts who show you how to prepare the VB6 code before the migration and how to manually fix all the issues that the tool left unresolved.

Read more user comments.