By Francesco Balena, December 2008

Unlike the majority of the language conversion products available on the market – which mainly attempt to convert code from one language to another – VB Migration Partner both converts the code and uses a support library to decrease the gap between VB6 and VB.NET and to ensure that the converted code really behaves as expected.

This white paper illustrates why we took this approach and the many benefits a support library for migrated VB.NET applications can provide. It is meant to be used by both developers and IT managers, regardless of their familiarity with .NET Framework programming. In some cases we couldn’t help showing short code snippets to prove a point, but you don’t need to understand what each line does to follow the line of reasoning.


Summary

In this article we will analyze each topic in a very detailed manner, with code samples and technical considerations. This is a short summary of what you can find:

  1. Language impedance: a support library can fill the gap between VB6 and VB.NET and support more keywords than by any other means.
  2. User interface issues: only a control library can perfectly mimic all the VB6 controls, their object models, and their features.
  3. Integration with the code generation engine: when coupled with a very sophisticated code generation engine, the support library can solve most of the issues that must be manually fixed if working with other, conversion software that use a more traditional approach.
  4. Preliminary work on the VB6 code: a support library can transparently support more VB6 features and can therefore eliminate or significantly reduce the need to prepare the VB6 code for migration, which in turn permits to keep the VB6 and VB.NET code in sync.
  5. Compilation errors: a support library exposes classes and methods with a VB6-like syntax, which help to reduce the number of compilation errors in the VB.NET code produced by the migration software.
  6. Runtime errors: by mimicking the VB6 behavior as closely as possible, a support library greatly reduces the efforts required to reach functional equivalence.
  7. Concise, readable, and maintainable code: a migration software that uses a support library doesn’t require to generate additional code to work around the differences between VB6 and VB.NET object models.
  8. Application advancement: a support library is by no means an obstacle to improving and extending the VB.NET application after the migration process has been completed.
  9. Performance optimizations: VB Migration Partner’s library exposes objects that can improve performance with very little effort on your part.
  10. Consulting and training costs: a support library makes the VB.NET language more familiar to VB6 developers and reduces the urge for specific .NET training during the migration process.
  11. Embedded debug features: VB Migration Partner’s library includes special functions that make tracing and debugging easier.
  12. Interoperability with VB6: by reproducing VB6 behavior as closely as possible, a support library allows you to reuse existing data files and/or exchange data with VB6 apps you don’t want to migrate at this time.
  13. Bug fixing: if you use a traditional conversion tool to migrate to VB.NET and the resulting application that has runtime bugs (which hasn’t), all the bug fixing activity is on your shoulders. If you deploy a migrated application with bugs that depend on our support library, Code Architects tech support will take care of them.
  14. Runtime royalties: registered users can freely redistribute VB Migration Partner' library with converted VB.NET apps, with no runtime royalties.
  15. Future upgrades: you can freely download future versions of our support library, with no additional or hidden costs.
  16. Source code: we can provide the source code to companies or organizations who need it.
  17. After-migration library improvements: VB Migration Partner users can benefit from future extensions to its support library, such as transparent support for ADO.NET and multi-lingual support.

1. Language impedance

Writing a VB6 to VB.NET code converter isn’t for the faint of heart, but isn’t overly complex either, because the two languages are very similar, or at least VB.NET offers a high degree of backward compatibility with its predecessor. (Just think of the On Error and Declare keywords.) From a 10,000-feet perspective, VB.NET is more akin to VB6 than to C# or other .NET languages. Under the hood, however, the two languages are quite different. In fact, one might say that many developers tends to underestimate the effort of a migration process because the VB6 and VB.NET look so similar, but aren’t.

We would like to claim that Code Architects invented the concept of support libraries to reduce language impedance, but of course we didn’t. In fact, VB.NET comes with two support libraries: Microsoft.VisualBasic.dll and Microsoft.VisualBasic.Compatibility.dll. Microsoft.VisualBasic.dll aims at making the VB.NET experience more pleasant for VB6 developers (who can find more familiar names such as MsgBox and Hex), whereas Microsoft.VisualBasic.Compatibility.dll provides additional support for VB.NET application created by the Upgrade Wizard, including support for controls such as DriveListBox and FileListBox, or for VB6 features that are missing in the .NET Framework, such as control arrays.

The main problem with these libraries is that they weren’t built with background compatibility in mind. As a matter of fact, in most cases they only vaguely approximate the original VB6 behavior.

Take the Get# and Put# file methods, for example. The Upgrade Wizard and similar tools map these methods to the FileGet and FilePut methods in Microsoft.VisualBasic.dll. Unfortunately these methods are far from being equivalent to the original VB6 methods: they don’t work well with UDTs and with values stored inside Object variables; they don’t behave in a consistent way if the file is opened for binary or random access; they have problems with arrays and fixed-length strings, and so forth. In short, you can’t trust the file methods in Microsoft.VisualBasic.dll for a robust migration, except in very simple cases.

While developing VB Migration Partner, we quickly realized that the file methods in the “official” VB.NET libraries were so crippled as to be nearly useless. This is why VB Migration Partner maps the Get# and Put# keywords to the FileGet6 and FilePut6 methods in our support library. We put a lot of work in these methods to ensure that they work as their VB6 counterparts as closely as possible.

File methods are just one single example. To get a more complete picture, just browse the Resource section of this website. VB Migration Partner solves all these issues by combining a smart code generator with a comprehensive support library.

Interestingly, all the conversion tools we are aware of also use a support library to reduce the gap between VB6 and VB.NET. Only, their library isn’t as complete and powerful as ours and can only solve a small subset of the immense set of differences between the two languages.


2. User interface issues

As serious as it may sound, language impedance accounts for less than 10-15% of the problems you face when migrating a UI-intensive VB6 application, in which case the real obstacle in reaching functional equivalence is the set of differences between VB6 and VB.NET controls. The number of these differences is so high that we can’t list all of them here (we are documenting them in the Resources section of this website). Here are just a few:

Missing controls: a few VB6 controls have no .NET counterparts, including ADO/DAO/RDO data controls, DataList, DataCombo, Animation, ImageCombo, UpDown, PictureClip, and SysInfo. A migration software that doesn’t use a support library can’t do much other than reusing the ActiveX control on the .NET form, which results in a less-than-robust application.

Missing features: even if a VB6 control has a .NET equivalent, many features aren’t available in the .NET world. For example, the VB.NET PictureBox can’t work as a container and the ListImage object doesn’t support anything similar to the Draw or the ExtractIcon methods, just to name a few common problems.

Graphics: You have to carefully remap all your Line, Circle, PSet, Point, and PaintPicture commands to GDI+ objects. Also, if you used GDI methods for advanced graphics, you’ll soon discover that .NET controls don’t have an hDC property that returns the handle to their device context.

Drag-and-drop: The .NET way to implement drag-and-drop is so different from the VB6 way that no migration tool even attempts to convert existing D&D code, hoping that you are skilled enough in both VB6 and VB.NET to do the conversion yourself.

Incompatible object models: even if a .NET control provides the same features as the original VB6 control, in some cases a 100% correct translation is impossible because the two controls have significantly different object models. The most obvious case is the VB6 CommonDialog control, which maps to as many as six .NET controls, some of which are incompatible with the original control.

To get an idea of how incompatible object models can make migration more difficult, try the following experiment. Drop a Toolbar and an ImageList control on a VB6 form, bind the Toolbar to the ImageList control, and then write this code to add a few items to the Toolbar when the form loads: 

        Private Sub Command1_Click()
            ' add a plain button
            Me.Toolbar1.Buttons.Add , "New", "New file", tbrStandard
            ' add a button menu
            Dim btn As Button
            Set btn = Me.Toolbar1.Buttons.Add(, "first", "a menu", tbrDropdown)
            btn.ButtonMenus.Add , "Open", "Open file"
            btn.ButtonMenus.Add , "Save", "Save file"
        End Sub
                    
        Private Sub Toolbar1_ButtonClick(ByVal Button As MSComctlLib.Button)
            ' react to clicks on the toolbar
            MsgBox Button.Caption & " has been clicked"
        End Sub
                    
        Private Sub Toolbar1_ButtonMenuClick(ByVal ButtonMenu As MSComctlLib.ButtonMenu)
            ' react to clicks on the button menu
            MsgBox ButtonMenu.Text & " menu has been selected"
        End Sub

This is the simplest code you can build with a Toolbar, yet it delivers as many as 12 compilation errors and 4 upgrade warnings if converted with the Upgrade Wizard that comes with Visual Studio 2008. It takes a while to get rid of all these compilation errors but, above all, you have to completely re-write all the VB.NET code, because .NET Buttons.Add method works differently and the ButtonMenus collection doesn’t even exist. Needless to say, you also have to manually rewire the Click events to the right .NET object.

A question arises quite naturally: why should you use a migration software if you then need to manually fix all the code manually? As a matter of fact, re-creating a working .NET form by hand takes less time, in this and many other cases.

You can expect that a more sophisticated (and expensive) migration software can handle this simple case more efficiently, but no tool that relies exclusively on code transformation can avoid all compilation and runtime errors in all cases. Keep in mind that a remarkable amount of manual work is always required.

By comparison, thanks to its support library approach, VB Migration Partner can handle virtually all the differences between VB6 and VB.NET related to controls and their object model. This feature alone can save you weeks or months in a complex migration initiative. (...and yes, the above code compiles and runs fine at the first attempt, if you use VB Migration Partner.)



3. Integration with the code generation engine

Our competitors would like you to believe that VB Migration Partner can achieve its higher success ratio only thanks to its support library. The implicit message is “Code Architects uses this library trick to migrate with fewer errors, we prefer to focus on morphing the VB6 code into readable and maintainable VB.NET code.”. We talk about readability and maintainability later in this article, but for now let’s get rid of this false myth.

VB Migration Partner is above all a very sophisticated code translator that solves most of the common migration issues by means of advanced code generation techniques exclusively. Consider the following migration issues:

  • Array with nonzero LBound index
  • Preservation of auto-instancing (As New) semantics
  • Refactoring of Gosubs calls into distinct methods
  • Conversion of On...Goto and On Gosub methods
  • Automatic initialization of Type...End Type blocks that contain arrays, fixed-length strings, and As New objects
  • As Any parameters and AddressOf keyword used with Declare statements
  • Correct cleanup of recordsets, database connections, and other IDisposable objects
  • Optional conversion of On Error statements into Try-Catch blocks
  • Type inference to detect the best data type for Variant/Object variables
  • Merging of nested IF statements, using short-circuiting and the AndAlso operator
  • Fully automatic migration of VB6 project groups
  • Refactoring of ByRef arguments into ByVal arguments if possible

We can solve all these migration issues thanks to our sophisticated code generation engine, with no aid from our support library. As of this writing, our competitors don’t support the majority of the features in this list.

Note: at least one competing product claims to support the migration of VB6 project groups). If you read closely, however, it turns out that “automatic” conversion is split in two phases; before running the second step, you are required to manually fix several issues related to ByRef vs. ByVal arguments, interface creation, renaming, and object types.

No manual fixing is ever necessary with our software. VB Migration Partner is the only migration software that offers truly automatic conversion of VB6 project groups.


4. Preliminary work on the VB6 code

All migration tools we are aware of – including Upgrade Wizard and its derivatives – require that you “fix” the VB6 code before attempting the migration. This is necessary to get rid of those language constructs that the tool doesn’t know how to migrate, for example Gosub, On Goto/Gosub, As Any parameters, arrays with nonzero LBound.

As you can imagine, preparing the VB6 code for migration is easier said than done. Changing the bounds of an array involves more than just editing a Dim statement, because you also have to check all the places where the array is used, where the array is passed to other methods, where the array is written to disk, etc. Just as important, you must run all your QA tests to ensure that your edits didn’t introduce subtle bugs in the VB6 code. This task alone can take one or two weeks in a large VB6 application.

VB Migration Partner eliminates – or dramatically reduces, even in the worst cases – the need for this preliminary step thanks to its code generator engine and its approach based on the support library. Even better, you can “fix” the original VB6 code by adding migration pragmas. Being just special remarks, pragmas are guaranteed not to change the way the VB6 code works, thus you can continue to distribute and evolve the VB6 code with confidence, because the “fix” can’t change its behavior. No expensive and time consuming QA tests are required.


5. Compilation errors

In addition to providing features that couldn’t be implemented otherwise, a support library offers the benefit to reaching the “zero compilation error” sooner than by any other means. Our support library provides stub “do-nothing” methods that have been added only to make the compiler happy. For example, like all other tools in this area, VB Migration Partner doesn’t support a few properties of the App object, such as OleRequestPendingMsgText or OleServerBusyTimeout. However, these members have been implemented in the library and don’t cause a compilation error. They do cause a compilation warning, though, which allow you to quickly analyze all those occurrences while being able to launch the migrated project.

When the application is up and running, you can set the VB6Config.ThrowOnUnsupportedMembers global flag to True. By doing so, all calls to stub methods now throw an exception and can’t go unnoticed, so you can be sure that you will get rid of all these calls before releasing the product to your customers.


6. Runtime errors

Interestingly, the effectiveness of a code migration software is usually measured in terms of how many compilation errors can be found in the generated code, as if reaching the “zero compilation errors” stage were the main goal of a migration initiative. If you browse our competitors' literature, a relatively little space is devoted to the time and effort required to move from there to the “zero runtime errors” stage, which is clearly what really matters.

In a separate article we demonstrated that VB Migration Partner converts to VB.NET with at least 5x fewer compilation errors than the Upgrade Wizard on the average, even before adding migration pragmas. We ran our tests on a mix of open source VB6 projects that represents a good mix of the challenges you face in migrating a business app (database access, data-binding, lots of controls, graphics, drag-and-drop, etc.). Incidentally, our competitors never published the results of running their tools on open source VB6 apps. Go figure why!

Avoiding compilation errors is only the first problem to solve in a migration project, and is also the simplest one. After all, you can fix most compilation errors by just looking at the messages in Visual Studio’s Error List window and using commands such search-and-replace and code refactoring. The only important goal is delivering a .NET application that runs without errors and that is 100% functionally equivalent to the original VB6 project.

Unfortunately, reaching functional equivalence with the original VB6 code is the most complex step in a migration project. In our experience, when using a traditional code converter such as Upgrade Wizard the effort required to get rid of all runtime errors and reach true functional equivalence is at least 2-3 times more expensive than just fixing compilation errors. In many real-world cases, it can be up to 10 times more expensive.

A support library can significantly reduce the time needed to achieve functional equivalence. This is the most important benefit of a support library.

Thanks to its library, VB Migration Partner generates VB.NET code that behaves exactly like the original application, or at least as closely as possible. Our support library accounts for virtually 99% of the behavioral differences between the two languages. In fact, it’s easier for us to document the minor differences that we do not support than the other way around. For example, read the KB articles that explain the few differences between VB6 and VB.NET versions of the StatusBar control, the Toolbar control, and the UpDown control. Not bad if you consider that the Upgrade Wizard doesn't support any of the styles of the StatusBar (date, time, capslock, etc.) and doesn't even attempt to convert the UpDown control (see image below) .


7. Concise, readable, and maintainable code

Some developers – especially those working for competing companies – try to scare you away from VB Migration Partner, claiming that our software produces code that can’t be easily extended and maintained. To break this false myth, let’s consider a very simple VB6 code fragment: 

        Private Sub Text1_KeyPress(KeyAscii As Integer)
            ' convert the pressed key to uppercase, but ignore spaces
            If KeyAscii = 32 Then KeyAscii = 0: Exit Sub 
            KeyAscii = Asc(Chr$(KeyAscii))
        End Sub

Here is the code converted by VB Migration Partner. Thanks to the library approach, the syntax and semantics of the KeyPress event is preserved. The generated VB.NET code is as concise, readable, and maintainable as the original method: 

        Private Sub Text1_KeyPress(ByRef KeyAscii As Short) Handles Text1.KeyPress
            ' convert the pressed key to uppercase, but ignore spaces
            If KeyAscii = 32 Then KeyAscii = 0: Exit Sub 
            KeyAscii = Asc(Chr(KeyAscii))
        End Sub

This is the code produced by the Upgrade Wizard and - with minor variations - by any tool that attempts to achieve functional equivalence exclusively by manipulating code: 

        Private Sub Combo1_KeyPress(ByVal eventSender As System.Object, ByVal eventArgs As _
                System.Windows.Forms.KeyPressEventArgs) Handles Combo1.KeyPress
            Dim KeyAscii As Short = Asc(eventArgs.KeyChar)
            If KeyAscii = 32 Then KeyAscii = 0 : GoTo EventExitSub
            KeyAscii = Asc(Chr(KeyAscii))
        EventExitSub: 
            eventArgs.KeyChar = Chr(KeyAscii)
            If KeyAscii = 0 Then
                eventArgs.Handled = True
            End If
        End Sub

It’s hard to consider this code as concise, readable, or maintainable – unless, of course, you consider a 2x increase in size as an example of “conciseness” and you think of the GoTo keyword as “readable and maintainable.”

You might believe that you have this problem only with the “free” Upgrade Wizard, and that other commercial VB6 conversion tools wouldn’t suffer from it. You’d be wrong, though. Just look at how Artinsoft’s VB Upgrade Companion converts the same code:

        Private Sub Text1_KeyPress(ByVal eventSender As Object, ByVal eventArgs As _
                KeyPressEventArgs) Handles Text1.KeyPress
            Dim KeyAscii As Integer = Strings.Asc(eventArgs.KeyChar)
            ' convert the pressed key to uppercase, but ignore spaces
            If KeyAscii = 32 Then
                KeyAscii = 0 
                If KeyAscii = 0 Then
                    eventArgs.Handled = True
                End If
                Exit Sub
            End If
            'UPGRADE_ISSUE: (1058) Assignment not supported: KeyAscii to a non-positive constant 
            'More Information: http://www.vbtonet.com/ewis/ewi1058.aspx
            KeyAscii = Strings.Asc(Strings.Chr(KeyAscii).ToString()(0))
            If KeyAscii = 0 Then
                eventArgs.Handled = True
            End If
            eventArgs.KeyChar = Convert.ToChar(KeyAscii)
        End Sub

We now have 13 (thirteen!!) executable statements instead of the original 3, and still have to check the UPGRADE_ISSUE message to ensure that it doesn’t affect functional equivalence.

For more examples of “conciseness” and “readability”, just try the Upgrade Wizard and its siblings with other common event handlers, such as a MouseDown or MouseMove. Then laugh aloud...


8. Application advancement

Typically, you migrate a VB6 app to .NET because you want to later extend it with new features.

Our competition tries to convince you that using a support library makes future extensions difficult if not impossible, because the .NET application is tied to a library over which you have no control.

Let’s see what the reality is and why .NET applications generated by VB Migration Partner are in no way limited in future expansions:

  • You can add standard .NET forms to migrated applications, or standard .NET controls to migrated forms
  • The controls in our library inherit from the corresponding .NET controls, thus you can easily access all the features of the .NET Framework, including the most powerful properties, methods, and events.
  • If you later want to add features that are missing in the original VB6 app – say, drag-and-drop or data-binding – you can implement them using the standard .NET syntax. The controls in the library are full-fledged .NET controls and can behave as such.
  • You can easily revert to standard VB.NET keywords, if you don’t like using methods in our library.

The bottom line is: a support library doesn’t hamper future application advancement in any way. Read the “Interoperability with VB6” section for an example of this concept.


9. Performance optimizations

In some cases, a support library can offer you dramatic performance improvement with very little work on your part. For example, many .NET developers know that you it’s often possible to optimize a piece of code that uses string concatenation, by replacing the string variable with a StringBuilder object, as in this piece of VB.NET code that extracts data from an ADODB recordset: 

        Dim text As String = ""
        Do Until rs.EOF
            text = text & rs("FirstName").Value & " "
            text = text & rs("LastName").Value & ControlChars.CrLf
            rs.MoveNext()
        Loop
        text = UCase(text)

Using a StringBuilder object instead of a plain String for the text variable requires major changes in the generated code, because you have to replace the & operator with the Append method and use the ToString method any time you pass the StringBuilder to a method that expects a string.

To make life easier for developers, VB Migration Partner comes with a special class named StringBuilder6, which is basically an enhanced StringBuilder class that supports the & operator and implicit conversions to/from the String type. In fact, you can optimize the above piece of VB.NET code by modifying just one line of code: 

        Dim text As StringBuilder6 = ""

The speed improvement can be really astonishing.

VB Migration Partner’s code analyzer is enough sophisticated as to automatically suggest where using a StringBuilder6 object can positively affect performance. Our software offers similar speed improvements in other fields as well, for example when working with collections.


10. Consulting and training costs

It isn’t a secret that developers working at a migration project must be adequately skilled in both VB6 and .NET. If a company has worked mainly with VB6 in recent years, odds are that its developers be much more familiar with VB6 than with the .NET Framework. If you are the boss of such a company and you are planning a migration to VB.NET, your options are:

  1. you hire one or more .NET skilled developers
  2. you hire a consulting company that specializes on .NET
  3. you train existing VB6 developers to use VB.NET instead
  4. you do nothing of the above, and just hope for the best

All these options are expensive. Even the last option is going to cost you a lot, because less skilled developers typically need more time to complete the migration to .NET, which indirectly increases the cost of the migration process.

A support library isn’t a magic wand, yet it can contribute to reducing training and consulting costs. Language commands and control members have same name, same syntax and – more important – same behavior as in VB6. Our customers feel themselves immediately at ease when working with VB Migration Partner and its library.

As a result, in most cases you don’t need to hire .NET developers or external consultants. As a matter of fact, our customers are making the best of VB Migration Partner without any support from Code Architects other than our standard tech support.

In most cases the online documentation and the huge mass of KB articles available on our web site is enough for our customers to solve most common migration issues without even asking our tech support.

Training costs can’t be avoided in the long run, though. If you plan to extend your migrated app with new features – such as ADO.NET, Web services, and advanced graphics – your developers must become familiar with .NET, its immense power, and its many idiosyncrasies. However, you can focus on delivering a working .NET application first, and later use your consulting budget for extending the application with new features.


11. Embedded debug features

VB Migration Partner’s library comes with a few test and debug features already built-in. For example, if one of your customer reports a fatal bug, you can produce a detailed log by just changing one line in your code: 

        VB6Config.LogFatalErrors = True

You don’t even need to recompile the application, if you were smart enough to read the LogFatalErrors value from the configuration file. Once you receive the log file from your customer, you know exactly where the fatal error occurred. With some luck, you might be able to fix the problem very quickly and suggest a fix in a few hours.

In short, a support library can help you track down your bugs more easily and in less time. By the way, we are planning to greatly improve the debugging and testing capabilities in forthcoming versions, therefore you can expect even more tangible advantages in the near future.


12. Interoperability with VB6

A support library is also helpful to solve interoperability issues with VB6 apps that you don’t want to migrate right away. Consider the following example:

  • The VB6 application uses binary or random files to store data
  • The VB6 application uses text files to store user preferences, such as color, window position, etc.

VB Migration Partner handles both cases quite nicely. All binary and random files are accessed by means of the FileGet6 and FilePut6 methods in our support library (see the “Language Impedance” section, earlier in this article), which guarantee a very high degree of compatibility with files created by VB6.

All configuration data stored in text files also works correctly, because VB.NET apps generated by our migration software understand twips and all the ScaleMode settings (including user-defined modes). Also, the numeric value of enum types is the same as under VB6, therefore you can read an integer from a file, assign it to a property, and achieve the same result as in VB6: 

        ' next line works because the Move method understands
                VB6 coordinate systems
        txtName.Move( GetControlLeft("txtName"), GetControlTop("txtName") )
        ' next line works because the Alignment property understands VB6
            enum values
        txtName.Alignment = GetControlAlignment("txtName")

As mentioned in the “Application advancement” section above, you aren’t cornered in VB6 syntax, though. VB Migration Partner’s controls are true .NET controls, therefore you can use the “native” methods and properties instead, if you later extend the form with more features: 

        txtName.Location = New Point(100, 200)
        txtName.TextAlignment = HorizontalAlignment.Center

13. Bug fixing

You are in the software industry, you know that a bug-free program hasn’t been invented yet. Migration products are no exceptions (of course, it applies to our competition as well).

That said, we have no problem in conceding that the support library that comes with VB Migration Partner might have some quirks. On the other hand, the short yet intense history of our product proves that we fix our bugs very quickly. Our customers know that we often provide a bug fix within a few hours, or a couple days in the worst cases. Many of them praised our tech support team too, as you can read here and here.

Let’s focus on facts that anyone can ascertain.

Consider two migration programs, one that uses a support library (VB Migration Partner), another that relies on code transformations exclusively (a competitor’s tool). Let’s now see what consequences a bug in these programs has on their respective customers.

Say that you are a Code Architects’ customer who found a problem in how the ComboBox control reacts to data-binding. This is what is going to happen:

  1. You contact our tech support and provide enough details to let us reproduce the problem, for example a fatal error log automatically produced by VB Migration Partner’s support library (see the “Embedded debug features” section).
  2. We fix the bug and send you a new version of the library.
  3. You distribute the new library to your customers, who only have to overwrite the existing DLL and restart the application.

You might wait a few hours or a couple days. In either case, we do the bug fixing, not you.

Let’s see now what happens if you are using a competing tool and one of your customers reports of a malfunctioning caused by an orphaned delegate object or the missing cleanup code for an IDisposable object. (Incidentally, our competitors don't generate code to work around these issues, therefore this isn’t exactly an hypothetical example!). These are the steps you must go through:

  1. You have to understand what went wrong. (Other tools give you no built-in debugging features to give you a hint, sorry...)
  2. You have to work out a solution, which may require a lot of .NET expertise. Not surprisingly, many .NET developers don’t even know what orphaned delegates are and how you can avoid them.
  3. Once you have devised a robust solution, you have to apply it to your application. Odds are that you have myriads of objects that aren’t correctly disposed of. This step can take a loooong time...
  4. Finally, you can recompile all your EXEs and DLLs, make a setup procedure, and ship it to your customers.

Looking at the two sequences, 9 out of 10 developers would prefer to migrate using a support library, regardless of what our competitors would like you to believe. The bottom line: Fixing a bug caused by a library requires less time and effort on your part.

Using a support library isn’t different from using a custom control from any other company, be it Microsoft or a control vendor such as Infragistics or Component One. If you use a 3rd-party control you become dependent, to a degree, on the company who authored the control. If you bump into a bug in the .NET Framework or in a 3rd-party control, you have to wait until the manufacturer fixes the bug. Microsoft might take months or even years to fix even serious bugs in the .NET Framework; component vendors and tool makers such as Code Architects are typically more reactive, and our customers can attest it. Some even felt the urge to blog about it.


14. Runtime royalties

We know that a few vendors charge for their runtime libraries. This isn’t the case with Code Architects. VB Migration Partner users don’t pay one cent for the ability to distribute its runtime library.


15. Future upgrades

In addition to not paying for royalties, VB Migration Partner users don’t pay for future upgrades of the support library. If you purchased VB Migration Partner 1.xx you will be allowed to download all future 1.xx releases of the support library. If we fix more bugs, your automatically benefit from those fixes. If we add minor features, you get them for free.

It’s like a life-time insurance on your migrated code.



16. Source code

Our competitors like to remind you that we don’t provide the source code of our support library. This is only partially correct. More precisely:

  1. We know that a few large companies and government agencies need the source code of any 3rd-party library or control they use, therefore we are willing to comply with these requirements. There is a cost involved and some papers to be signed, but it’s doable.
  2. We are willing to sign a code-escrow agreement, according to which we deliver the library’s source code to a third party company. If a given event occurs - typically, if Code Architects goes out of business – the 3rd-party company will send the source code to our customers. There is a cost involved and some papers to be signed in this case too, but it can be done.
  3. Should we discontinue VB Migration Partner, the library’s source code will be provided free of charge to all registered customers.

You should ask yourself whether having the library’s source code is really so important. Consider that:

  • You never have the source code of neither the VB6 runtime’s source code nor many of the ActiveX controls you worked with. Nevertheless, you created a lot of great VB6 and VB.NET applications.
  • You can modify the behavior of a control by inheriting from our class and overriding its methods and properties. You don’t need the library’s source code for doing that.
  • Even if we sell you the source code (see case A above), we don’t encourage you to modify it. In fact, we don’t provide any form of support for doing that, including paid consulting.
  • We don’t offer tech support for applications that use a support library that has been recompiled by our customers.

As explained in the “Bug fixing” section, using a support library is conceptually similar to using a 3rd-party custom control. You might have used ActiveX controls for years without owning their source code. Or maybe you had purchased the source code but never even opened those files. The truth is, owning the source code of a piece of software is one thing; being able to modify it, possibly to extend it or fix a bug, is a completely different – and much more complex - story. In most cases you should never modify someone else’s source code, unless you know well what you’re doing.

Nevertheless, some developers claim that having the source code allows to understand what happens behind the scenes, when something doesn’t work as expected. This is correct. However, .NET developers can use tools such as Reflector to explore the inner workings of the .NET Framework without having its source code. We used Reflector to detect many undocumented behaviors and bugs of the .NET Framework and the Microsoft.VisualBasic DLL. You can do the same with our support library, if you wish.


17. After-migration library improvements

A runtime library offers a few non-obvious advantages too. For example, not only it simplifies bug fixing: it even solves bugs before they occur. In fact, we periodically publish new versions of the library, which contain all the cumulative bug fixes implemented so far. If a bug is especially serious, we will publish a fix immediately and alert our users via our newsletter or blog. You indirectly benefit from the experience of all VB Migration Partner’s users all over the world. You and your customers.

An example of these advantages has been obvious in VB Migration Partner version 1.20. In this version we added support for “classic” (VB3-style) drag-and-drop and for DDE-related members. These two features were the only major VB6 features that were missing in previous VB Migration Partner, thus we decided to fill this gap. When we released version 1.20, all VB Migration Partner customers just had to overwrite the old support library with the new one and – presto! – their migrated apps magically supported both drag-and-drop and DDE. (Minor adjustments had to be performed manually in some cases.)

Future improvements aren’t limited to bug fixes, though. We at Code Architects specialize in writing application frameworks for our customers, and we plan to extend our support library with characteristics that can add a lot of value to your VB.NET apps. This is just a short list of features that future VB Migration Partner releases might offer:

  • Automatic support for ADO.NET in lieu of ADODB, to improve performance and scalability of database-intensive applications
  • Advanced trace and debugging features
  • Multi-lingual support: would you like to effortlessly support additional languages in your code and forms?
  • Design-time features at runtime: give your customers the ability to customize their forms’ appearance and behavior.
  • Automatic support for Windows Presentation Foundation (WPF) forms and controls
  • Integration of Windows Workflow Foundation (WF) technology
  • Additional application features (login dialogs, integrated scheduler, etc.)

We are already working on some of these items. Expect interesting announcements in the near future.


Conclusions

It took over 5,000 words to explain all the benefits of the support library approach in a migration project. Some benefits might be very important to you, some might be negligible. For example, you don’t have to worry about training if your company already hired skilled .NET developers, and you can overlook the extra speed that a library can give you if your application doesn’t suffer from performance problems.

In all cases, we suggest that you carefully weigh all the options available and compare VB Migration Partner with migration tools that rely exclusively on code transformations.

If you have only 15 minutes to spare, we recommend watching this tutorial video on the convert-test-fix methodology.

For a more detailed analysis, you have an entire website to explore. Unlike our competitors, we put the entire product documentation available to everybody before they purchase our product, including an exhaustive Knowledge Base that grows every day.