FRANCESCO BALENA ON VB MIGRATION

 

Does a support library add any performance overhead?

clock May 9, 2011 13:08


This is a recurring question among our prospect customers. The general idea is that a support library can't avoid adding some overhead to the migrated application.

However, this is just another false myth and in fact we can easily prove that a support library can often make your application faster, not slower. Let's divide the explanation in four parts.

1) Basic member wrappers
The vast majority of the classes and methods in VB Migration Partner's library are just very thin layers over the corresponding .NET control. For example, this is the code for the SelText property of the VB6TextBox control:

Public Class VB6TextBox
   Inherits System.Windows.Forms.TextBox

   ' ...(all other properties and methods have been omitted)

   Public Property SelText() As String
      Get
         Return MyBase.SelectedText
      End Get
      Set(ByVal value As String)
         MyBase.SelectedText = value
      End Set
   End Property
End Class

NOTICE that the VB6TextBox class inherits from System.Windows.Forms.TextBox, therefore it is a 100% native .NET control. Only the few members whose name or behavior differ from the VB6 counterpart need to be overridden. Also, notice that re-exposing a .NET property with the VB6 name ensures that migrated apps work also if the control is accessed via late-binding. None of our competitors can’t handle the late-binding case correctly and they require that you manually tweak the migrated code.

As you see, the wrapping property just forward the call to the base class. Interestingly, the .NET Just-in-time compiler uses an optimization technique known as code inlining, which guarantees that the SelText property is sidestepped and that the client app directly invokes the SelectedText member in the base class. In short, no performance penalty occurs for simple wrapping members.

2) Wrappers with additional statements
A method in the support library may include additional statements, in order to preserve functional equivalence with the original VB6 code. For example, in VB6 an assignment to the SelStart property also resets SelLength and brings the cursor into view. We keep the functional equivalence by adding a couple statements in the wrapping property:

Public Property SelStart() As Integer
   Get
      Return MyBase.SelectionStart
   End Get
   Set(ByVal value As Integer)
       MyBase.SelectionStart = value
          MyBase.ScrollToCaret()
          ' in VB6 setting SelStart resets Sellength
          MyBase.SelectionLength = 0
   End Set
End Property

The code inlining optimization technique described above avoids the call overhead even in this case, yet it is true that these additional actions may introduce a minor overhead.

The point not to be missed, however, is that developers working at the migration should add those statements anyway to preserve functional equivalence. Having these statements located in the library instead of in the migrated code brings several advantages, including

  • Developers save time because apps migrated work well at the first attempt
  • Developers don’t need to be “migration gurus” nor they need to be aware of the thousands major and minor differences between VB6 and .NET
  • The code in the migrated app is more readable and can be maintained more easily, because it doesn’t contain all the extra (and obscure) statements that ensure that VB.NET code works exactly like VB6.
  • The migrated app is therefore smaller and loads faster

Please notice that over 95% of the methods and properties defined in our support library fall in either case 1 or 2. None of them adds any performance penalty to migrated apps. Better, they make your code more concise and faster!

3) Methods that have no .NET equivalent
Fewer than 5% of the members in VB Migration Partner's support library have no direct equivalent in the .NET Framework. For example, this is the case with graphic methods (Line, Circle, etc.), drag-and-drop statements, and DDE keywords. Of course you *CAN* implement graphics and drag-and-drop under .NET, but consider that this isn't an easy task because the VB6 and .NET programming models are very different. Not surprisingly, only VB Migration Partner can automatically convert these VB6 features, thanks to its support library.

Because is no direct .NET counterpart exists and no other VB6 conversion tool supports these features, it's impossible to measure the overhead that our library adds in these cases. At any rate, we concede that an expert .NET developer might be able to re-write the graphic or drag-and-drop portions of your software so that it runs faster than the code migrated from VB6.

As usual, the decision is a trade-off of cost/time against performance. VB Migration Partner can convert a graphic-intensive VB6 application into a reasonably fast .NET graphic application. Maybe you can make youre code run faster if you manually rewrite those graphic statements using native GDI+ methods. On the other hand, you're surely going to spend a lot of time and money in the process, without any certainty to achieve a result that is noticeably faster than what VB Migration Partner delivers to you in a few seconds and for free.

4) Helper performance-wise classes and methods
Finally, don't forget that in many cases when a support library can actually make your migrated code faster, not slower. VB Migration Partner's support library includes several helper classes that have been designed with performance in mind. A great example of this concept is the StringBuilder6 helper class, that can speed up string concatenation by two or three orders of magnitude, as explained here.

The StringBuilder6 class is nothing but a wrapper for the well-known System.Text.StringBuilder class, thus you might optimize the migrated code by using either class. The big difference is that using the StringBuilder6 class only requires that you insert one single SetType pragma in the original VB6 code, whereas using the standard StringBuilder forces you to manually modify the generated code in many places, because the StringBuilder object calls for a different syntax.

VB Migration Partner's library also offers auxiliary classes to speed up collections, and the VB6Collection helper class is much faster than the standard VB.NET collection in nearly all circumstances, as explained in this article.

VB Migration Partner's support library is written in standard VB.NET, therefore all the performance improvements it offers could be theoretically achieved by modifying the VB.NET code generated by any conversion tool, for example Artinsoft's VBUC. However, these manual optimizations require some time (often, a LOT of time) and are error-prone, therefore in practice they are seldom carried out unless the migrated code is just too sluggish to be used.

 

Bottom line: VB Migration Partner and its support library generate .NET apps that run faster than those produced by any other competing product, and rarely require that you manually optimize the generated code.

Still not convinced? Then wait no longer: ask for VB Migration Partner Trial Edition and compare it against any other VB6 conversion tool, or against your .NET programming skills. The faster wins.



The quest for transparency

clock May 6, 2011 11:27

I always have fun at browsing our competitors' website, especially when they have to explain which VB6 features they support or don't support, or when they attempt some bold comparisons with THEIR competitors (that is, us!)

For one, I can't help admiring the intentional vagueness that they often use when describing which controls their tool support. To them "supporting a control" is a binary property, it's either TRUE or FALSE.

Just to give you a concrete example, all the VB6-to-.NET conversion tools claim that they support the PictureBox control. Alas, they forget to mention that they

  • don't support the PictureBox as a container
  • don't support graphic methods, double buffering, and custom ScaleMode settings
  • don't support DDE
  • don't support drag-and-drop (neither "classic" nor OLE flavors)
  • don't guarantee that all events are fired or are fired in the correct order
  • ... and counting

As you look at it more closely, the "We support the XXX control" claim is void, unless you explicitly specify which features are supported, which ones aren't, and those that are supported only partially. The devil is the details, as they said, and many customers discover these details only after purchasing the software.

We believe this approach is ethically questionable and for this reason we always made the entire documentation for VB Migration Partner is available online, so no one can get unpleasant surprises AFTER purchasing our software. In addition to the manual we also make available the entire Knowledge Base, which orderly lists all known defects and limitations (and how to work around them). For sure this isn't a common attitude in the world of software, as our customers can attest.

In our quest for the highest transparency, we have prepared a long and detailed document (also in PDF format) that explains all the features as well as all the limitations of VB Migration Partner's support library, including the slightest differences from VB6, and - above all - how to work around them. This information has always been available on our website, but finally our customers have a single document that gathers the information spread in hundreds of different KB articles.

It is a safe bet affirming that all software vendors maintain a list of known issues with their tool, as we do, but you won't find this list available on our competitors' websites.... Too embarassing?



[NEW RELEASE] VB Migration Partner 1.33 is available

clock February 22, 2011 19:54

Less than three years after its debut, VB Migration Partner is such a mature and complete product that it's hard to add new features. For this reason, the new version comes as many as five months after the 1.32 version and can be considered as nothing more than a "maintainance build".

Among the few noteworthy new features is the AddAttribute pragma, which allows you to associate a .NET attribute with a program element (a class, a method, a variable, etc.). This attribute is especially useful to specify MarshalAs attributes for the elements of a Type structure in a way that is compliant with the convert-test-fix methodology, so that you don't have to manually modify the generated .NET code and can safely re-migrate the same piece of code over and over. (In previous versions, adding an attribute required some wizardry with the PostProcess pragma).

We have also fixed about 40 minor bugs, thus VB Migration Partner is more robust than ever. The complete list of additions and bug fixes can be found in the VERSION HISTORY.TXT file.

As usual, registered users will be notified of the new version (and will be brought to the download page) the next time they launch the software.



[CASE STUDY] Xcel Energy, USA

clock February 15, 2011 11:22

Xcel Energy recently used VB Migration Partner to migrate a VB6 application consisting of multiple projects for a total of 120,000 lines of code (LOCs). The migration project was a complex one, because of many constraints and requirements, such as the adoption of Rockford Lotcha's CSLA.NET framework, but our conversion software proved to be up to its reputation. In the words of our customer:

VB Migration Partner was able to correctly parse and convert all of the Forms and ActiveX controls to VB.NET. After analyzing the output and reviewing their on-line knowledge base (which is quite extensive), two pragmas were inserted to reduce the number of conversion errors to a handful in most of the programs. All of the forms could be edited without any further intervention. Grid controls that could not be converted were initially left as red rectangles. Within 2-days, all of the source code was cleaned up with no compiler errors.  This meant that the existing presentation layer could be converted from VS6 to VS2008 – so the VB Migration Partner option works very well as part of an overall approach.

120,000 LOCs were translated to the zero-compilation-error stage in 2 days! This is pure productivity!

You can read the entire Xcel Energy case study here

 



How to convert 11,000 lines in a few minutes!

clock February 14, 2011 11:11

Transoft is a large, UK-based system integrator with branches in the US. Last year Transoft became Code Architects' partner for migration services. Last week I asked Transoft's Fiona Oliver why they opted for using VB Migration Partner rather than other migration tools. Here's her answer:

I used VB Migration Partner to convert a small program (11K executable lines) that enables connections to multiple ODBC data sources in separate windows, allows entry and execution of SQL statements, and displays the results. It also allows for metadata export and import to local files. It compiled with no errors and ran with a single pragma to insert a single line of code. In comparison the Visual Studio Upgrade Wizard produced code with over 102 compilation errors. I was very impressed!

This comment makes it evident the huge gap between VB Migration Partner and other "traditional" converters such as Upgrade Wizard and other VB6 converters that are based on the same translation engine.

If you are curious of how VB Migration Partner can help you in your migration efforts, you just need to download our VB6 Bulk Analyzer, run it against your VB6 project, and send us the report.



Guess which VB6 migration tool delivers fewer compilation errors?

clock February 2, 2011 16:48

Migration from VB6 is a serious matter and choosing the wrong approach might cost you a lot of time and money, or even putting at stake the entire migration project.

For this reason we always recommend all our prospect customers to test all the available solutions and tools before making their final choise. This is the experience of Solent, France:

Facing a problem of Microsoft VB6 obsolescence, we spent weeks defining the best way to migrate our customer’s specific enterprise application from VB6 to VB.NET. We tried different COTS migration tools but the results were not the expected ones: too many things to complete manually after the conversion. The idea to develop a proprietary migration tool was in our mind when we finally found VB Migration Partner. It was the solution we needed.

Indeed, with VB Migration Partner, we ended having to manually deal with only about 100 compilation problems compared to more than 10k given by other tools. Its iterative process with replayable corrections (thanks to "pragmas") was a very useful functionality in order to reach a complete validation of the 150K lines of code application we had to migrate. During this process, we found and fixed a large number of execution problems in our application due to migration. A reactive technical support and the clear "knowledge base" on the website helped us to identify problem causes and to correct them. In only 2 months, we delivered a fully-tested and renewed .NET application to our customer.

Damien SEURU
Project Manager, SOLENT

Completing the migration of 150K LOCs in a couple months is surely a great example of the high productivity you can reach with VB Migration Partner. Likewise, having to solve just 100 compilation errors instead of 10,000 gives a very clear idea of how far ahead we are if compared to our competitors!

You can read more about our customers and their experience in our Testimonial page.



One more customer praising the convert-test-fix approach

clock January 24, 2011 16:28

We received from a German customer these notes, which we gladly (and proudly) publish. As usual, boldface is mine:

On today’s market you have to be able to deliver new application versions at any time. Customers don’t accept statements like: “Sorry, we are in a migration process. We can’t add the feature you need. We can’t even fix a bug within the next year.” VB Migration Partner is the only tool which enables us to enhance the application during the migration process.

It was soon clear to us that the library approach is the way to go. VB6 and VB.NET are too different. It’s not possible for a machine to close this gap. Without VB Migration Partner we would have ended up implementing our own library. The "pragma" concept enables us to run the migration and as a result get .NET code we can compile. With pragmas migration is an ongoing process. We migrate, make changes on the generated code, express these changes in terms of "pragmas" and migrate again. During these migration cycles we are still able to change, enhance and deliver the old VB6 application. VB Migration Partner is a software which gives you the feeling the developers work with it themselves. They know the problems in migration processes and they offer solutions that work.

Conclusion: If you have unlimited time, money and manpower it might be worth having a closer look on the VS built in migration tool. If one of these resources is limited you choose VB Migration Partner.

Martin Gerhold
Dietrich’s AG / Germany

Some customers ask us whether it is feasible to migrate to .NET without a support library. This customer found the answer by himself: the support library is the only reasonable mean to automatically deliver code that runs correctly. In fact, he says that without VB Migration Partner they would end up building their own library. Fortunately we at Code Architects have spent many man/years to extend and fine-tune our library, thus you can focus on less boring facets of the business.

Equally interesting is that this customer realized that only VB Migration Partner is able to convert VB6 apps that are being modified during the process: this is the methodology we know as “convert-test-fix”. All other conversion tool work on a snapshot of the VB6 codebase, and when the migration seems to be completed you suddenly realize that you still have to re-sync your migrated code with the new features and bug fixes that have been added to the original VB6 code in the meantime.

Not really smart, uh?...but this is how all other VB6 conversion tools work.Wink

You can read more comments from actual VB Migration Partner users in our Testimonials page.



[HOWTO] Leverage naming conventions to assign a specific type to implicitly-declared variables

clock January 14, 2011 09:27

One of our customers came up with the following question:

I have some code in my project that was developed by a person used to Fortran naming conventions. In his code, variables starting with letters I to N are meant to be integers while others are Double. Ideally, there would be a pragma such that we can indicate that undeclared variables starting with letters I to N are to be declared as integer while other undeclared variables should be declared double. Is this possible?

The short answer to this question is that the original developer could have used the DefInt and DefDbl VB6 directives to force the type of all undeclared variables. Adding these directives just before migration wasn’t an option, however, because they might introduce very subtle bugs if the developer failed to adhere to the naming rule in some cases. Also, the approach based on Defxxx directive can’t be applied if the naming convention is based on multiple-character prefixes, as such “int” for integers and “dbl” for Double.

Even though VB Migration Partner doesn’t provide a pragma that perform the requested task, what our customer asked for is quite in reach for it. In fact, if you use the DeclareImplicitVariables pragma, then all variables that weren’t explicitly declared are rendered as “Object” variables and are prefixed with 05B1 warning “The xxx variable wasn’t declared explicitly”. Thanks to this detail, using a PostProcess pragma to replace the variable type isn’t hard at all:

'## PostProcess "(?<=05B1\): The '(?<name>[I-N].*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Short", True, False, ""
'## PostProcess "(?<=05B1\): The '(?<name>[A-Z-[I-N]].*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Double", True, False, ""

If the developer used the “int” and “dbl” prefixes, the pragmas become:

'## PostProcess "(?<=05B1\): The '(?<name>int.*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Short", True, False, ""
'## PostProcess "(?<=05B1\): The '(?<name>dbl.*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Double", True, False, ""

Just another example of how super-flexible our VB Migration Partner can be Laughing



Welcome our new partner Datamatics Global Services

clock December 15, 2010 11:11

I am proud to announce our partnership with Datamatics Global Services, a leading service company with offices in US and India. Datamatics Global Services has an impressive success story and can claim over 10,000 man/years of software migration services.

The fact that such an experienced group of developers has choose Code Architects' VB Migration Partner as the main tool for converting VB6 to .NET is yet another confirmation of the high power and flexibility of our software.

Read more about our partners here.

 



[NEW RELEASE] VB Migration Partner 1.32 is available

clock November 18, 2010 14:59

Earlier this week we made VB Migration Partner v.1.32 available to all registered users.

Unlike some competitors of ours, who attempt to generate hype by releasing a new major version every few months - and nevertheless are still far from matching the core functionality of VB Migration Partner - we prefer to stay with version 1.xx and yet adding new important features at every new release.

As with all previous versions, all the new features were inspired by customers' requests. In spite of this being a "minor" new release, the list of added features is really impressive:

  • Save time during the test stage with the new Trace-Match feature: you can now easily produce a trace both under VB6 and the converted VB.NET program, compare the two trace files, and quickly spot behavioral differences between the two. More info here.
  • the new SetOption ExcludeMethodBody pragma is an important addition that permits to migrate subsets of large VB6 projects. You can now convert projects with hundreds and hundreds forms and classes, by focusing on just 5 or 10 forms/classes each time. No more the dreaded "Too many compilation errors" warning!
  • the new PreProcess and PostProcess pragmas allow you automatically launch external programs before or after the migration, thus providing the ability to customize the converter's behavior with no need to create a specific extender. 
  • Partial support for the ObjPtr undocumented VB6 function
  • Partial support for the DrawMode property of Form, Picturebox, and UserControl objects. You can now do rubber-banding in .NET, no need for manual fixes!
  • Ability to export and save the contents of the Activity Log pane
  • Menus in MDI forms have been enhanced and now behave exactly as in VB6.
  • OLE drag-and-drop now works also between TreeView nodes, and we added support for the DropHighlight property of both TreeView and ListView controls
  • ... and counting.

As usual, all the details are in the VERSION HISTORY.TXT file that comes with the new setup, including the complete list of all the bugs that we caught since last release.

To download the new version, just lauch VB Migration Partner on a computer connected to the Internet: a message will alert you that a new version is available and will bring you to the download page on our website.





Follow Francesco Balena on VB6 migration’s group on

LinkedIn


VB Migration Partner - Subscribe to our feed RSS  blog RSS
 
AddThis Feed Button
 
 

Home blog
 
AddThis Social Bookmark Button


 

Sign in

Search

Calendar

<<  November 2014  >>
SuMoTuWeThFrSa
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

Archive

Categories

 

Microsoft Regional Director
Microsoft is a registered trademark of Microsoft Corporation in the United States and other countries and is used under license from Microsoft
 

My programming tools



VB Migration Partner

 

My books


Programming Microsoft Visual Basic 6


Programming Microsoft Visual Basic 2005: The Language


Practical Guidelines and Best Practices for Microsoft Visual Basic .NET and Visual C# Developers