VB Migration Partner

SIS is new Code Architects' partner !

Francesco Balena — Fri, 26 Jun 2009 02:20:00 -0700

SIS is a Microsoft Certified Partner who has used VB Migration Partner to successfully migrate VB6 apps, including a large legacy application counting. (You can read the entire story here.)

In these months they have gained an impressive knowledge of both our software and of migration issues in general, and we are now proud to announce that SIS and Code Architects have signed a partnership agreement, according to which SIS will offer both VB Migration Partner and custom migration services.

That's good news for companies based in Austria and Germany and wishing to convert their VB6 code to VB.NET!

Support for "classic" (VB3-style) drag-and-drop !

Francesco Balena — Wed, 17 Jun 2009 19:39:00 -0700

Since its early beta versions VB Migration Partner has always supported the conversion of OLE drag-and-drop features, including the OLEDragMode and OLEDropMode properties, the OLEDrag method, and all OLExxx events. All these members are fully supported and developers don't need to manually edit either the VB6 code and the migrated VB.NET code.

In the past year our customers have shown to greatly appreciate this feature, thus we are very proud to announce that we have extended the support to "classic" drag-and-drop, i.e. the DragDrop and DragIcon properties, the Drag method, and the DragOver and DragDrop events. As for OLE D&D, all the features are fully supported and no manual edits are required, neither before nor after the migration.

It almost goes without saying that VB Migration Partner is the only VB6-to-VB.NET conversion tool that fully supports "classic" drag-and-drop. The new features will be included in forthcoming version 1.10.01, due in one-two weeks.

In addition to demonstrating that Code Architects is relentlessly improving VB Migration Partner, this announcement also proves many of the advantages of a rich support library (as opposed to other conversion tools).

No need to re-migrate a VB.NET application that has been already migrated. Registered users of previous versions only need to download the new support library and - presto! - their converted VB.NET apps will automatic leverage D&D support!
No need to learn how drag-and-drop works in VB.NET and no need to revise how it worked in VB6, which in turn means fewer training costs and fewer issues if the original VB developers have left the company in the meantime.
No need to purchase a new license for VB Migration Partner: as our customers know, users of version 1.xx have the lifetime right to download any future 1.xx versions of the support library, free of charge!

If you want to learn more about the many advantages of our support library, read 17 Reasons for Using a Support Library in Migration Scenarios.

If you want to learn more about the differences between VB Migration Partner and other conversion tools, read Migration Tools: Feature Comparison Table.

Code Architects joins the Visual Studio Industry Partner program

Admin — Mon, 25 May 2009 01:55:00 -0700

Three days ago, on May 22, it was both VB Migration Partner's birthday and the day when we released our 1.11 version, a new milestone in VB6-to-VB.NET conversion technology.

Later in the same day, we were also "officially" accepted by Microsoft Corp. as part of the Visual Studio Industry Partner program. It's an important acknowledgement of Code Architects's role in helping developers and software companies move their legacy VB6 apps to .NET.

You can read the entire story in this press release.

Happy birthday VB Migration Partner... and welcome version 1.11 !

Admin — Fri, 22 May 2009 02:33:00 -0700

Exactly 365 days ago we released VB Migration Partner 1.00, after a 8-month public beta period and 2.5 years of intense development.

A lot of things have happened in these 12 months. In spite of us being relatively unknown outside Italy, our software gained immediate popularity among VB6 developers, who had been waiting for a product like VB Migration Partner since the .NET launch in 2002, that is when they realized that the Upgrade Wizard included in Visual Studio is a little more than a toy and that other VB6-.NET conversion tools leave much to be desired.

Understandably, the only people who weren't very happy of our debut were our competitors, whose products had something to be compared with, at last.

VB Migration Partner 1.00 included several unique features that couldn't be found in any other similar tool, including those that had been on the market for 6 years, such as support for Gosub and On Goto/Gosub statements, As Any clauses and callbacks in Declare, graphic statements, and drag-and-drop. One year later our competitors are still trying to catch up and are now slowly adding some of the features that we support since our earlier beta versions.

18 months after we launched the vbmigration website and unveiled our software, VB Migration Partner is still the only conversion tool that supports granularly scoped migration pragmas and the convert-test-fix methodology, both of which are essential in complex, real-world migration projects.

However, we didn't rest for long, and in September '08 we launched VB Migration Partner 1.10, also known as the Refactoring Release. Even if apparently we just changed the minor version number, we actually re-wrote the parser and conversion engine from scratch. It was a painful but necessary step, because we needed to support important features, such as refactoring of Gosub into separate methods, type inference, conversion of On Error into Try-Catch blocks, and a rename engine to ensure compliance with .NET coding guidelines.

A few days before the official release date an important customer asked for binary compatibility of .NET DLLs with the original VB6 component, and we managed to add that, too! Binary compatibility you can migrate an N-tier application in pieces, starting with the innermost data tier, so that you can use the business and user-interface tier to test the new components. It might look as a minor detail, yet it dramatically cuts test and debug time/cost and allows you to focus on the portions of the application where the introduction of .NET and the replacement of old, non-scalable COM components has the higher benefits.

Well, I couldn't find a better way to celebrate the VB Migration Partner's birthday than by announcing that we just released version 1.11 a few hours ago!

If version 1.10 was the Refactoring release, the new version 1.11 can be dubbed as the Variant release. We rewrote the portion of the conversion engine that deals with Variant variables and extended the special VB6Variant type in our library so that it now behaves in exactly the same way as the VB6 Variant data type, including full support for Null propagation, Empty and missing values, and arrays of arrays. All the methods in the support library can now take a VB6Variant and return a VB6Variant as necessary.

Support for null propagation simplifies the conversion of database-intensive projects to VB.NET more than any other feature, but we didn't stop there. The new version 1.11 also generates better code for late-bound properties and methods, for B-string functions (e.g. LeftB and InputB), and for non-Latin alphabets. As usual, you can read all the details in the Version History.txt file, in the setup folder.

Can your VB6 conversion tool handle null propagation?

Francesco Balena — Thu, 21 May 2009 03:13:00 -0700

If you have massively used Variants in your VB6 apps, the migration to .NET might be a nightmare. The best that the Upgrade Wizard and other tools can do is translating each “As Variant” into “As Object”, on the assumption that the Object type can do everything that a Variant does.

You shouldn’t be surprised to learn that this is one of the false migration myths, or is a gross oversimplification of the truth, to say the least. In fact, the .NET Object type lacks what arguably is the most useful feature of Variants: support for Null values and Null propagation in expressions.

Under VB6 a Variant variable can hold the special Null value and – even more important – all the string and math expression that involve a Null operand also deliver a Null Variant value. Virtually all database-intensive applications deal with Null values and have used null propagation to an extent. Now, let’s consider this VB6 code:

' rs is an ADODB.Recordset
Dim realPrice As Variant
realPrice = rs("Price")
realPrice = realPrice * (100 – rs("Discount")) / 100
If Not IsNull(realPrice) Then DisplayPrice(realPrice)

Under VB6, if either the Price or the Discount field is Null, the realPrice variable is assigned Null and the DisplayPrice method isn’t invoked. Now, consider the “canonical” VB.NET version of the above code:

Dim realPrice As Object
realPrice = rs.Fields("Price").Value
realPrice = realPrice * (100 – rs.Fields("Discount").Value) / 100
If Not IsNull(realPrice) Then DisplayPrice(realPrice)

Under .NET a Null database field returns a DBNull object – more precisely, the DBNull.Value element. The problem is, no math or string operation is defined for the DBNull type, something I consider one of the most serious mistakes Microsoft made in this area. As a result, the third statement throws an exception if either field is Null. So long, functional equivalence! Welcome, migration head-aches!

Null propagation is a serious problem not to be underestimated. One of our customers has found that, on the average, one out of 40 statements uses Variant expression and relies on null propagation. To put things in the right perspective, in a middle-sized real-world application you can expect to manually fix several thousand statements that use null propagation. What’s worse, there is no simple way to work around Null values in VB.NET, short of splitting all statements in portion and testing each and every subexpression for the DBNull.Value value.

If you use VB Migration Partner, you can solve the above problem in the most elegant and painless way. Just use the following project-level pragmas:

'## project:NullSupport
'## project:ChangeType Variant, VB6Variant

The NullSupport pragma tells VB Migration Partner to map some VB library functions – such as Left, Mid, Right, and a few others – to special methods that are defined in VB Migration Partner’s support library and that, not surprisingly, correctly return a Null value if their argument is Null (as they do under VB6).

The ChangeType pragma converts all Variant members – variable, fields, properties, methods, etc. – as the special VB6Variant type (also defined in VB Migration Partner’s support library) which redefines all the math, comparison, string, and logical operators to support null values.

Yes, this is all you need to add null propagation support to your VB.NET code! This feature alone can save you literally weeks in a real-world migration project. And don’t forget that VB Migration Partner is the only VB6 conversion software that supports Null values and Null propagation easily and automatically.

When you hear other vendors claiming that “our tool uses advanced artificial-intelligence-based techniques to ensure functional equivalence with the original VB6 code”, just ask them how it deals with Null values.

Announcing release 1.11

Admin — Mon, 11 May 2009 22:22:00 -0700

We at Code Architects have been working on the next release for a couple months now. It should have been released as version 1.10.05, but we have added so many important features that we decided to label it as version 1.11.

Here's a partial list of what you'll find in the forthcoming version:

smaller runtime library (about 1.66 MB) loads faster and takes less memory
improved support for Variants - our VB6Variant class now behaves very closely to the original VB6 data type
better support for "B-string" functions, e.g. LeftB and InputB)
byref/byval semantics are correctly handled also in late-bound calls (more info in upcoming blog post)
better support for Japanese characters and resources
better support for ActiveX controls

We should be releasing version 1.11 within the end of May.

[CASE STUDY] Migration of a 650,000 LOCs ERP system

Francesco Balena — Sun, 03 May 2009 04:42:00 -0700

We've just published a case study of a migration carried out by SIS, an Austrian Microsoft partner who used VB Migration Partner to convert a middle-sized ERP system (about 650,000 lines of code), with a good assortment of challenges. The part that I like most is the following paragraph (the boldface is mine):

During the software evaluation phase we run a 25K prototype through all the conversion programs. It took 2.5 hours to get a compilable and runnable VB.NET project with VB Migration Partner, and 13 hours with its closest competitor. The reduced effort, the ability to use pragmas and support for the convert-test-fix were the main reasons for choosing Code Architects’ software. Later we discovered that their tech support is also excellent.

It looks like VB Migration Partner allows you to convert VB6 apps to VB.NET about 5 times faster than its competitors. Interestingly, the ratio is virtually the same also for larger, real-worlds apps - as you can ascertain by reading our competitors' case studies related to applications of comparable size.

You can read the entire story here.

VB Migration Partner speaks Japanese

Francesco Balena — Fri, 24 Apr 2009 01:51:00 -0700

You can find Code Architects and VB Migration Partner mentioned in the VB Migration Center section, on Microsoft Japan's MSDN web site.

From there you can find links to our Japanese home page and to translated portions of our documentation.

[USER COMMENT] VB Migration Partner is the most productive migration software on the market

Francesco Balena — Fri, 17 Apr 2009 02:22:00 -0700

We just received this comment from a customer:

An initial migration compared migration tools from six vendors. It showed superior results for VB Migration Partner from Code Architects, which delivered fewer compilation and runtime errors than all its competitors. Its migration pragmas and the convert-test-fix methodology proved to be powerful and flexible enough to handle a large VB6 application (950K lines of code) with ease, the documentation is excellent, and Code Architects’ tech support has always been very responsive.

Dr. Otto J. Wiegele, CEO, SIS Datenverarbeitung GmbH

The boldface is mine, as I wanted to emphasize that our customer selected our VB Migration Partner after comparing as many as SIX competing products. They told us that they selected our software because it was twice as productive than the second item in the list.

'nuff said!

[NEW RELEASE] Version 1.10.04 is available

Francesco Balena — Tue, 24 Mar 2009 19:34:00 -0700

Last week we released VB Migration Partner 1.10.04. In addition to a few bug fixex, this new version features two new pragmas.

The new PreservePropertyAssignmentKind pragma solves a problem that is inherent to the translation of VB6 properties that have a Get, Let, and Set block. This problem manifests itself in relatively few cases, and in fact no one has ever documented it before. Not surprisingly, the Upgrade Wizard and other VB migration tools suffer from this limitation. You can find more details here.

The second pragma we added is SetPragmaPrefix, which allows you to decide the valid prefix (or prefixes) for pragmas. It indirectly allows to enable and disable a group of pragmas inserted in code and can be very helpful in advanced scenarios. For example, you might want to try different approaches when migrating, and this pragma frees you from having to delete and insert many pragmas for each different scenario. (This is just an example: you'll see the real power of this pragma in forthcoming releases.)

Accomplishing the impossible: VARPTR in VB.NET!

Francesco Balena — Sun, 15 Mar 2009 20:39:00 -0700

VB6 supports three functions – VarPtr, StrPtr, and ObjPtr – that were never officially supported by Microsoft, yet they have been extensively used by many expert VB6 developers. In fact, you badly need these functions when calling some especially complex Windows API functions. Of these functions, the most useful one is VarPtr, which returns the address of the memory location where the value of a variable is stored.

Neither the Upgrade Wizard nor any other VB6 migration tool supports the VarPtr keyword, thus I decided that our VB Migration Partner *had* to correctly convert it. Thanks to Google, I found out that the problem had been discussed at length in many forums, but no definitive solution has ever been found yet. You can write an implementation in unsafe C#, or an unmanaged DLL written in C or Delphi, but these solution would force us to distribute a separate DLL with VB.NET apps converted by VB Migration Partner, which I’d rather not to.

It took a while and a lot of thinking, but in the end I figure out a way to solve the problem. Yes, it is possible to write a VarPtr function in plain VB.NET, with only the help of a method exposed by the Windows API. Actually, you need just a few lines of code:

' -----------------------------------------------------------
' VARPTR implementation in VB.NET
' Part of VB Migration Partner’s support library
'
' Copyright © 2009, Francesco Balena & Code Architects
' -----------------------------------------------------------

Module VarPtrSupport
   ' a delegate that can point to the VarPtrCallback method
   Private Delegate Function VarPtrCallbackDelegate( _
      ByVal address As Integer, ByVal unused1 As Integer, _
      ByVal unused2 As Integer, ByVal unused3 As Integer) As Integer

   ' two aliases for the CallWindowProcA Windows API method
   ' notice that 2nd argument is passed by-reference
   Private Declare Function CallWindowProc Lib "user32" _
      Alias "CallWindowProcA" _
      (ByVal wndProc As VarPtrCallbackDelegate, ByRef var As Short, _
      ByVal unused1 As Integer, ByVal unused2 As Integer, _
      ByVal unused3 As Integer) As Integer

   Private Declare Function CallWindowProc Lib "user32" _
      Alias "CallWindowProcA" _
      (ByVal wndProc As VarPtrCallbackDelegate, ByRef var As Integer, _
      ByVal unused1 As Integer, ByVal unused2 As Integer, _
      ByVal unused3 As Integer) As Integer
   ' ...add more overload to support other data types...

   ' the method that is indirectly executed when calling CallVarPtrSupport
   ' notice that 1st argument is declared by-value (this is the
   ' argument that receives the 2nd value passed to CallVarPtrSupport)
   Private Function VarPtrCallback(ByVal address As Integer, _
         ByVal unused1 As Integer, ByVal unused2 As Integer, _
         ByVal unused3 As Integer) As Integer
      Return address
   End Function

   ' two overloads of VarPtr
   Public Function VarPtr(ByRef var As Short) As Integer
      Return CallWindowProc(AddressOf VarPtrCallback, var, 0, 0, 0)
   End Function
   Public Function VarPtr(ByRef var As Integer) As Integer
      Return CallWindowProc(AddressOf VarPtrCallback, var, 0, 0, 0)
   End Function
   ' ...add more overload to support other data types...
End Module

To understand how the trick works, let’s see what happens when you call the VarPtr method. The only line of code in this method invokes one of the overloads of CallWindowProc method. The CallWindowProc method takes five arguments, the first one of which is a delegate that must point to a method that takes four 32-bit values. CallWindowProc invokes the method pointed to by the delegate and passed the other four values to such a method.

The key point in this mechanism is that each CallWindowProc overload takes a value by-reference in its second argument – a Short and an Integer, respectively. This means that the CallWindowProc method (buried inside the User32.dll) receives the address of the Short or Integer variable. This address is a 32-bit integer and is passed verbatim to the VarPtrCallback method. This method in turn receives a 32-bit integer value with by-value semantics, which means that the address parameter now contains whatever value was pushed on the stack by the CallWindowProc method.

Let’s quickly recap: the VarPtr method pushes the address of the Short or Integer variable – that is, the value we are interested in – on the stack. This 32-bit integer is received by the CallWindowProc method (in User32.dll) and is sent to the VarPtrCallback method, which receives it in its first argument and returns it verbatim to the CallWindowProc method, which in turn returns it to the VarPtr method that can finally return it to the caller.

Notice that you might need to add more overloads for the VarPtr method (and the CallWindowProc method), to support data types other than Short or Integer. Just remember that you can’t use this technique with String, Objects, or other reference types. It doesn’t work with Boolean values, either.

Interestingly, you can use the VarPtr method with structures, provided that the structure doesn’t contain any String, Object, or Boolean elements. To get the address of a structure just use VarPtr on its first element, as in this example:

Structure POINTAPI
Public x As Integer
Public y As Integer
End Structure

Dim pnt As POINTAPI
Dim addr As Integer = VarPtr(pnt.x)

To prove that the VarPtr function works correctly, let’s use it together with the CopyMemory Windows API method to delete an element in an array by quickly shifting all the elements towards lower indices:

Declare Sub CopyMemory Lib "Kernel32.dll" Alias "RtlMoveMemory" _
   (ByVal dest As Integer, ByVal source As Integer, _
    ByVal numBytes As Integer)

Sub Main()
   Dim arr(1000) As Integer
   ' initialize the array
   For n As Integer = 0 To UBound(arr) : arr(n) = n : Next
   ' ...
   ' delete first element by shifting all elements towards the beginning
   ' of the array, then clear last element
   CopyMemory(VarPtr(arr(0)), VarPtr(arr(1)), UBound(arr) * 4)
   arr(UBound(arr)) = 0
   ' check that it worked fine
   For n As Integer = 0 To UBound(arr) - 1
      If arr(n) <> n + 1 Then Debug.Print("Wrong value at index {0}", n)
   Next
End Sub

In case you are wondering why you should use CopyMemory and VarPtr to shift all the elements of an array – instead of a plain For … Next loop – the answer is: execution speed. Under VB6 this technique was often used to significantly speed up array operations; the VB.NET compiler produces more efficient code and this technique is seldom necessary, nevertheless the ability to convert this code from VB6 without any major edits means that you don’t have to spend too much time trying to understand what the VB6 developer meant to do.

Please notice that this implementation of VarPtr works well in 32-bit applications only, and fails when running on 64-bit operating systems. To ensure that things work as expected and that 32-bit code is generated even when running on 64-bit versions of Windows, you must select the Target CPU = x86 option in the Advanced Compile Options dialog box, in the Compile tab of the My Project page. (Odds are that you have to select this option anyway when doing complex operations with pointers.)

Important warnings: working with memory addresses under .NET can be very dangerous, much more dangerous than under VB6. The reason is, the garbage collector can fire virtually anytime while the program is executing, therefore the address of an object can suddenly change and the unmanaged method (CopyMemory in above example) would receive the address of a memory area that doesn't contain the data any longer. The neat result would be either a wrong value or an application crash. When using this implementation of VarPtr under VB.NET keep the following points into account:

VarPtr is absolutely safe only when used to return the address of simple local variables, such as Short, Integer, Single, Double, or Date variables. Using local variables is safe because local variables are allocated on the stack and don't move even if an unexpected garbage collection occurs immediately after the VarPtr method returns but before the unmanaged method complete its execution.
Passing the element of a Structure is safe, but only if the Structure is held in a local variable (as opposed to a class field)
In all other cases, VarPtr isn't 100% safe and might occasionally deliver wrong results or crash the application. For example, it isn't 100% safe to pass VarPtr a class field or an element of an array, because array elements are stored in the managed heap and can be moved by the garbage collector (regardless of whether the array is stored in a local variable).
In a single-thread application the probability that a garbage collection occurs unexpectedly are very low and might even be considered as negligible, but they can't be considered as equal to zero.
You can further minimize the probability of an unexpected GC by avoiding calling methods and language functions (e.g. Left, Int, Abs) inside the call to the unamanged method but, again, you can't reduce this probability to zero.

To recap, except when you are in cases #1 and #2 above, the converted code will work most of the time, but it can't be guaranteed to work always.The only documented way to ensure that an object doesn't move in memory because of unexpected gargabe collection is by pinning the object, by means of methods exposed by the System.Runtime.InteropServices.Marshal class.

Even with this limitation, the VB.NET implementation VarPtr method is quite helpful when doing a quick-and-dirty migration - using VB Migration Partner or the Upgrade Wizard. You can use VarPtr to check that the converted code works as intended, but it is strongly recommended that you get rid of VarPtr before going to production. In the CopyMemory case see above, for example, you can do without the VarPtr by using a different overload of the CopyMemory method that takes by-reference arguments:

Declare Sub CopyMemoryByref Lib "Kernel32.dll" Alias "RtlMoveMemory" _
(ByRef dest As Integer, ByRef source As Integer, _
ByVal numBytes As Integer)

(This code works because the .NET Framework automatically pins every object passed by reference to an external method.)

Even better, you should do your best to avoid unamanged calls altogether and replace them with calls to methods of pure .NET objects.

All the white papers in one place

Francesco Balena — Sat, 21 Feb 2009 21:57:00 -0700

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

Francesco Balena — Sun, 15 Feb 2009 20:52:00 -0700

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

Francesco Balena — Wed, 11 Feb 2009 23:46:00 -0700

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
[PRB] 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

Francesco Balena — Tue, 10 Feb 2009 03:09:00 -0700

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