[CASE STUDY] Danske Bank Group Teller System converts 350,000 lines of VB6 code to VB.NET

clock August 7, 2009 09:56

Danske Bank is the largest financial enterprise in Denmark and one of the largest in the Nordic region. The Group Teller System was implemented in the Bank’s branches in 2001, and since then various new functionality has been developed for the system. Microsoft no longer supports the VB6 IDE, so the bank decided to convert it to the .NET platform.

Branch Systems in Retail Solutions were given the assignment to convert the Group Teller System from the VB6 platform to the .NET platform. The application consists of 350,000 lines of code, a fact that ruled out the option of manual conversion. The company therefore chose VB Migration Partner to support the conversion, since this tool is developed particularly to support conversions from VB6 to .NET. This decision has meant a fast conversion and also brought to a noticeably improved conversion quality.

”In terms of effort, using VB Migration Partner is significantly more efficient than manual conversion or rewriting from scratch, especially considering that banking applications require very rigorous testing plans. As a matter of fact, much of the effort was spent on quality assurance, as the project has been focused on securing a high quality of the finished product”, says Michael Munk Lerskov, Project Manager. "After the conversion the Group Teller System was successfully deployed on more the 2.000 clients. Training of the users was not needed because the user interface was similar to the interface of the VB6 version. This is an additional advantages of using VB Migration Partner, that the converted GUI is almost identical to the original one."

You can read the entire case study here.

Estimate total migration cost for existing VB6 conversion software

clock July 31, 2009 04:04

Every day we receive requests and queries from VB6 developers and companies who are interested in migrating their code to .NET. Migration a complex application to .NET is a serious matter, therefore it’s no surprise that virtually all our prospects plan to compare our software with the similar tools from the competition.

We take migration seriously and we take competition even more seriously. As a matter of fact, we entered this market niche only when we were sure we could offer the best VB6 software that could be possibly written. And that’s why we have continued to improve our VB Migration Partner until it offered support for virtually all major VB6 features, including outdated features such as “classic” drag-and-drop and DDE.

Some other companies in this market have a different perspective, though, and some of our competitors prefert to cut the list price instead of improving their software to match all the VB Migration Partner’s features. A recent example: One of our competitors has dropped their list prices twice in a few months, in an obvious attempt to compensate for all the features that their product lacks.

Which brings up an interesting question: is the list price the “correct” way to estimate how expensive migration tools are? Isn't the total cost of migration a better criterion for selecting the right conversion tool?

All the real-world migration experiences and case studies show that greater part of migration costs is related to the manpower needed for manual tasks that are to be completed before and after the mere action of passing the VB6 code through the conversion software. In the big scenario, the cost of the migration tool is a very small fraction of the total cost, often in the range 5-10% or even lower. Therefore, when comparing migration tools the most “correct” selection criterion should account for the manual labor that each tool saves you

Some time ago we published a very detailed white paper that compares VB Migration Partner with other VB6 conversion tools. The document clearly illustrates that VB Migration Partner outperforms the competition under virtually all aspects, yet it doesn’t really emphasizes which supported features impact on the total cost and duration of the migration process. Here we remedy with the following short summary.

1. Functional equivalence: VB Migration Partner can handle even the most subtle differences between VB6 and VB.NET, including true auto-instancing (As New) semantics, by-reference ParamArray, correct disposal of database connection and other COM objects, thread-safe behavior for multithreaded components, 100%-compatible file I/O statements, and the many methods that behave slightly differently in VB6 and VB.NET. These features can dramatically cut the time required for testing the migrated application.

"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." (from a case study by SIS, an Austrian Microsoft Partner)

2. Variant and Null values: VB Migration Partner can (optionally) translate Variants into the special VB6Variant type, which behaves exactly like the VB6 type. It even supports Empty and Null values, which is a lifesaver if you are migrating a database-intensive application that uses Null values in expressions and assignments. By comparison, all other conversion tools simply convert Variant into the Object type, which in practice means that you have carefully test each and every statement that might be using a Null or Empty value.

Note: one of our customers is converting a very large VB6 application that makes extensive use of Variants; they estimated that VB Migration Partner saved no fewer than 3-4 man/moths just because of its support for Variants and Null values. We will provide more details when the migration is completed.

3. Late-binding method calls: VB Migration Partner comes with a library of .NET controls that expose the same properties and methods as the original VB6 controls. This detail ensures that your code works fine after the conversion to .NET, even if the control is accessed in late-bound mode. If you use another conversion tool you must manually rewrite each and every statement that uses late binding. If your VB6 code uses many Variant, Object, and Control variables, this task alone can keep you busy for weeks.

4. Support for *all* VB6 keywords and features: if your VB6 app uses GoSub, On Goto, or On Gosub statements, using a conversion tool other than VB Migration Partner means spending at least a few minutes on each of these keywords. The problem might be more serious if your VB6 code relies on other, less common features - such as Dynamic Data Exchange (DDE), ADO data sources or data consumers - because you’d be forced to re-write large portions of your code. Implementing a reliable communication infrastructure based on .NET remoting or WCF may take one week or two if you aren’t a .NET guru, or it takes ten seconds flat if you use VB Migration Partner.

5. Graphic statements: VB Migration Partner supports virtually all VB6 graphic capabilities, including the Line and Circle methods, double-buffering (the AutoRedraw property), and user-defined system coordinates (ScaleMode property). VB Migration Partner lets you can convert a graphic-intensive VB6 application in a matter of seconds. Any other conversion tool takes days even for the simplest graphic project, because none of them supports these graphic features.

For examples of painless conversion of graphic-intensive VB6 code, have a look at EGL25, TypeNSign, Stars, Barcode Generator, BC-52, and MP3 Player applications in our Code Sample section. (We even have fully playable versions of classic games such as Tetris, Pacman, and Space Invaders!)

6. Windows API calls: all our competitors are behind VB Migration Partner in how they deal with complex Windows API calls, such As Any and callback (AddressOf) parameters in Declares statements. Our VB Migration Partner goes even further: it automatically fixes undocumented issues caused by string immutability and orphaned delegates, recommends the best “pure .NET” replacement for 300+ common Windows API calls, and automatically performs the substitution automatically, if possible. You can read more here.

7. Rich user interface: in theory all conversion tools support all VB6 user interface features; in practice tools from our competitors require that you manually fix each individual form. An indirect evidence of their limits is that none of our competitors dares to offer examples of real-world VB6 forms and the corresponding .NET form, because they would be obliged to mention all the manual fixes that are necessary to have a working .NET application. Also, none of our competitors even gets near VB Migration Partner’s support for more advanced UI features, such as drag-and-drop (both OLE and “classic” flavors), popup menus, dynamically created controls (the Controls.Add method), and 100%-compatible object models for complex controls such as TreeView, ListView, Toolbar, and StatusBar.

Tip: When comparing conversion tools, have a look at the many differences between VB6 and .NET controls, prepare a list of those that may be important for you, and ask each vendor whether their tool can handle them.

8. Staged migrations: VB Migration Partner is the only conversion software that can convert a large N-tiered VB6 application one DLL at a time while preserving the binary compatibility with the original VB6 components. Binary compatibility means that you can reuse the VB6 user interface to launch and test the converted .NET components, and you can even reuse your automatic test procedures, if you have any. You can even hit the market with a “hybrid” VB6 / .NET solution earlier, if you need to do so. If ease of testing and reduced time-to-market are important to you, the choice is obvious.

9. The convert-test-fix methodology: A real-world migration process may take weeks or months, and you might need to extend or modify the original VB6 code before the migration is complete. All other tools on the market work on a snapshot of the VB6 code, therefore once the migration is ended you’ll have to manually modify the .NET code to preserve the functional equivalence with the VB6 application. This process takes time and is error prone, and can be very expensive. You don’t incur in this added cost if you adopt our convert-test-fix methodology, which in turn is based on migration pragmas (another VB Migration Partner’s unique feature).

"The batch processing and code-test-fix methodology will allow us to convert a changing code base without making the same changes twice, once in VB6 and again in VB.Net." , said Brian Olson, Actuarial Systems Corporation, USA.

10. Documentation, code samples, licensing, and support: A realistic estimation of total migration costs must include the time needed to become familiar with the migration software and its idiosyncrasies, peculiarities, and defects. In this respect, nothing beats VB Migration Partner’s online manual and the vast knowledge base, which we update and improve almost every day with tips, code examples, and workarounds.

We believe so much in our software that we offer lifetime warranty on VB Migration Partner’s support library: if you are a registered user of version 1.xx you have the right to download future 1.xx versions of the library. (For more details, please read our EULA.) Compare our approach with the time-limited license that most of our competitors offer, and you’ll have a clearer idea of which product can really save your time and which one can waste your money.

As for the quality of tech support, here is what some of our customers have to say:

"The documentation is excellent, and Code Architects’ tech support has always been very responsive."
Dr. Otto J. Wiegele, CEO, SIS Datenverarbeitung GmbH

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

"The Code Architects Team always solved all our doubts and problems, often in a matter of hours. Francesco Balena in person replied to the toughest queries about COM marshaling and object disposal. It was a pleasant surprise to find such a competent team and a company that is willing to extend their support to issues that aren’t strictly related to their product."
Stefano Baldi, Engineering PLM Solutions, Italy

"Any issue that I raised was answered positively on a next day if not next hour basis also made a huge difference. It's really as close to having VB Migration Partner's support team work in my office as one could get!"
Ara Ashikian, P.Eng., President, Structural Concepts Ltd, Vancouver, BC - Canada

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

clock May 3, 2009 10:42

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.

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

clock April 17, 2009 08:22

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!

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

clock February 1, 2009 05:51

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

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

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

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

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

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

Marco Meneo
ProgeSoftware, Italy

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

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

Read more user comments.

Comments from a VB.NET consultant

clock January 7, 2009 04:22

When we began our work on VB Migration Partner, we were aware that we had to make our product much better than the Upgrade Wizard and other conversion tools on the market, and that we had to backup our product with first-class, knowledgeable, and swift tech support. We are delighted that our customers realize that our approach makes a big difference.

Here is the abridged version of a blog post by Jugo Arsovski, a VB.NET consultant who used the Upgrade Wizard and then our VB Migration Partner to migrate an VB6 application by one of his customers. (Boldface is mine.)

I started Visual Basic 2005 Upgrade Wizard and after few steps I had converted .NET application. Oh my god! It was the worst converted code I’ve ever seen in my life. I ended up with zillion errors and warnings. It was practically useless code. I really had no idea where to start from. Almost every line in the project was underlined with red or green. I spent about 5 hours just trying to clean it up so I could understand some errors better. With that 5 hours I spent I only got about 1/1000 way through it so that should say how bad it was.[...]

I installed the VB Migration Partner on my computer and then ran the application. You wouldn’t believe that I was used to the GUI after only two or three minutes. It was love on first sight. lol

I have not spent a single minute on reading the help files. It is so simple to use that it is an absolute delight to work with. Actually all I had to do was to open VB6 project and then to click the "Convert to .NET" toolbar button (F5). Yes it was that simple. Only two steps and I had the VB6 application converted.

I ended up with only 65 errors and 17 warnings. I believe it's worth mentioning that this is nontrivial project, involving thousands of executable lines, a lot of methods, classes, DLL's etc. I am telling you this so you clearly understand that the initial 65 errors are relatively few, and seeing that was a real revelation to me. If i judge by the time it took to convert this application then this tool is certainly for all kind of migrations, beginning with the small and progressing to the huge ones (even those with millions executable lines). [...]

All the errors were related to certain interface but, honestly, i didn't know how to handle it. That’s why I contacted the VB Migration Support. I must say that I was pleasantly surprised by their efficiency and quick response. Actually this is very interesting part. To my great satisfaction I was privileged to communicate with Mr. Francesco Balena. [...]  

Isn't it brilliant that the author also leads the tech support team? No doubt this gentleman knows very well, that support is so essential in overcoming the initial dismay for automatic conversion tools. He contacted me the next day after I sent him an email and answered a ton of questions including the most important one, how to fix the remaining 65 errors.

As you can guess I was able to fix all the errors in the next ten minutes after Francesco's answer and finally compile the VB.NET project. Yep! It worked like a charm

I clearly remember when Jago contacted our tech support. He asked several tough questions, so I decided to reply personally. He was having a problem with a 3rd-party GIS type library which exists in both COM and .NET versions. One of the interfaces in the COM version had to be mapped to the corresponding base class in the .NET version. He solved his problem by simply adding a PostProcess pragma to the original VB6 code.

Producing only 65 compile errors in a large project is a great accomplishment by itself, but the ability to eliminate most of these compilation errors with just one pragma tells even more about VB Migration Partner power.

In case you didn't notice, however, the most interesting part of this story is the very last sentence:  It worked like a charm. Cool

It confirms that converted VB.NET apps often works fine at the first run once you eliminate the (relatively few) compilation errors. This is only one of the 17 advantages of VB Migration Partner's support library

Feedback on VB Migration Partner's support

clock December 22, 2008 12:57

A good migration tool would be nothing without an adequate tech support. That's why we invest all our energies to answer our customers' request as quickly as possible. At times this is difficult because we have so many customers overseas. At times we work on Saturdays so that everything works fine on Monday morning. I personally write the majority of KB articles, to share our knowledge among users and make our tool easier to use. 

It's a lot of effort, but it's so rewarding when a customer gives us such a great feedback:

Structural Concepts Ltd. has been developing Virtual Bridges for over 10 years. The unique next generation bridge engineering software is being used on a number of notable projects and design competitions.

In order to take advantage of the increased available memory in MS Vista 64 as well as to take advantage of multi-core processors, the large VB6 software base is being migrated to MS Visual Studio.Net. It was important to proceed in an efficient manner while still being able to continue using and expanding the existing version of Virtual Bridges. While the architecture of the software was very well thought out, any thought of carrying out the migration process manually or with partial conversion tools would have been out of the question. Although proceeding step by step using COM interopt was initially contemplated, it quickly became apparent that the process and debugging worflow would be too inefficient.

By some luck, I came accross VB Migration Partner's web site. Based on prior first hand knowledge of Francesco Balena's excellent VB text books, I was sold even before the product was released. Once it was released, I immediately purchased it and put it to good use.

This is the part I like most. (The boldface is mine.)

It is absolutely clear that VBMP is an essential tool for the migration of any real project. Frankly, given the exemplary support from the lead developer and author of in my opinion the finest VB textbooks out there, I could only proceed with full confidence. Given that any issue that I raised was answered positively on a next day if not next hour basis also made a huge difference. It's really as close to having VB Migration Partner's support team work in my office as one could get!

Ara Ashikian, P.Eng.
President, Structural Concepts Ltd
Vancouver, BC

It's worth noticing that Structural Concepts is migrating a VB6 app to VB.NET while extending and updating the VB6 code at the same time. This is the kind of wonder that only VB Migration Partner's convert-test-fix methodology can offer. No other VB6 conversion tool even comes close.

Exploring version 1.10 - Staged migrations and binary compatibility

clock November 25, 2008 04:33

Last week I blogged a lot about the new features in VB Migration Partner 1.10, including Gosub refactoring, dead code removal, type inference, and If merging. In this post I illustrate a new exciting feature that makes new version 1.10 even more powerful and versatile.

When migrating large N-tier applications you typically want to adopt the so-called staged migration or phased migration approach, in which you convert one component at the time while still keeping the bulk of the application in VB6. There are actually two different flavors of staged migration:

In-out: you start converting data (inner) components, then proceed outwardly with business components and finally with user interface components

Out-in: you start converting user interface (outer) components and then proceed towards business components, and finally data (inner) components

The approach you take usually depends on your priorities and the very reasons why you’re migrating the VB6 code. If you want to improve the user interface you’re likely to choose the Out-in option; on the other hand, if you are migrating to .NET to leverage its superior scalability, its ability to communicate via WCF, and its smaller memory footprint, odds are that you’d like to implement the In-out scenario.

All the migration tools on the market can handle the Out-In scenario quite easily: if you convert a VB6 client application that references one or more COM component you get a .NET Windows Forms application that preserves all the references to the original COM objects and will therefore work exactly like the original VB6 client. So far, so good.

Things become less simple if you wish (or need to) adopt the In-Out scenario. In this case you'd have to generate a VB.NET component that is binary-compatible with the original component being migrated, so that all the existing VB6 clients continue to work with the new .NET component as they did with the original COM component.

Well, the interesting thing is that neither the Upgrade Wizard nor any other tool on the market, as far as we know, can generate binary-compatible .NET components. No other tool other than VB Migration Partner, that is, because we just added this important feature to release 1.10, as a response to a request from a customer.

Making the migrated VB.NET component binary-compatible with the original VB6 component – and therefore compatible with all existing VB6 clients – is as easy as adding a project-level BinaryCompatibility pragma:

    '## project:BinaryCompatibility

VB Migration Partner generates a ComClass attribute for each public class in the generated VB.NET project; this attribute specifies the GUIDs of the original coclass, class interface, and event interface of the original VB6 class. In addition, a project-level Guid attribute in AssemblyInfo.vb is generated so that the .NET assembly has same GUID as the original type library. Finally, the Register for COM Interop setting is enabled in the MyProject property page. The neat effect of all these operations is that the .NET DLL is fully compatible with the original COM DLL and all existing VB6/COM clients can continue to work as before but use the new .NET DLL instead. (Clients don’t need to be recompiled.)

The BinaryCompatibility pragma is ignored and no warning message is emitted if the VB6 project type isn’t ActiveX DLL or if VB Migration Partner can’t find a COM DLL to be used to extract coclass and interface GUIDs. Notice that you can also use the BinaryCompatibility pragma at the file level, if you want to preserve binary compatibility with only a subset of the classes defined in the original COM component.

Interestingly, you might want to use the BinaryCompatibility pragma even if you aren't adopting the staged approach. In fact, even if the .NET components don't have to be compatible with the original COM components when the entire application is migrated, it is useful to preserve the compatibility until all the portions of the application have been converted, because it allows you to test a .NET component using existing COM clients.

Achieving binary compatibility requires more than just adding a few GUIDs and attributes, though. There are many subtle issues to be solved, for example enums, events, collection classes, apply the right MarshalAs attribute to UDT members, and a lot more. You need to wrap Public fields in properties and might need to transform a class into an interface before exposing it to COM clients.

In practice, to create a .NET component that is binary-compatible with an existing COM component you need to be a COM Interop guru and have a lot of time to spare… or you can just try out VB Migration Partner 1.10 Wink

VB6 Bulk Analyzer, a command-line tool to explore multiple VB projects

clock June 11, 2008 10:26

We routinely spend a lot of time at our customers' site, to help them in their migration needs. If you haven't written an application's source code, understanding what the migration challenges are is a difficult and time-consuming process. It gets quickly much worse if the application is scattered over dozens or hundreds VB6 projects, as is often the case with N-tier (DNA) Visual Basic applications. In such cases, even getting a broad idea of how large the application is, how many forms it has, which controls it uses, and which technologies it relies on is a nightmare. On top of that, if the application is really huge, few people in the company (if any) have a 360° view of the entire application.

For this and other reasons, this week I decided to lock my office door and build the VB6 Bulk Analyzer tool. It's a simple command-line utility that gathers a lot of information about all the VB6 projects and source files inside a specified directory tree and then creates a concise but quite thorough report. You can download the beta build here.

Using this tool is quite easy: just open a command window, move to the root of the directory tree that contains all the VB6 source files that you want to parse, and run the utility. I will show the name of the files being processed, and then a summary of all the code it has parsed. If you parse more than a few dozens files, odds are that the relevant information will scroll away from the window, but you also have a permanent copy in the file named VBAnalyser_Report.txt, in the current directory. The tool supports a few options too, such as /quiet for omitting file names, /out to select a different report file, and /help to display a short explanation. You can also specify multiple folder names, in case your source code is scattered in directories that don't have a common root, as in this example:
       VB6ANALYZER c:\firstapp c:\secondapp  /out:c:\report.txt

The report file contains much useful info, including:

  • number of projects and source files, grouped by type
  • statistics about the source code (code lines, empty and remark lines, etc.), number of methods, properties, etc.
  • statistics about ActiveX classes (grouped by their Instancing property, number of MTS classes, etc.)
  • all the type libraries used in all projects, with how many times the typelib is referenced
  • names of all used controls and components, with a count beside each control
  • list of all the Declare definition, with number of occurrences of each declare
  • list of problematic keywords (GoSub, On...Goto/Gosub, VarPtr, ObjPtr, StrPtr, etc.), with number of times the keyword is used
  • list of problematic data types (Variant, fixed-length strings, etc., with number of times the keyword is used
  • list of problematic control properties, methods, events (e.g. members related to classic Drag-and-drop or DDE)
  • list of problematic constants (e.g. adOpenDynamic and adOpenKeyset means that a piece of ADO code can't be easily ported to ADO.NET)
  • list of COM classes that are instantiated via CreateObjects
  • list of OLEDB data providers explicitly mentioned in a connection string

VB6Analyzer is quite precise, especially if you consider that it doesn't really interpret the VB6 source code. It uses plain regular expressons, yet it doesn't suffer from "false matches" (eg. a keyword that appears in a remark or in a quoted string). Regular expressions make it very fast: on a 3GHz system it analyzes over 600K characters per second, or nearly 9,000 lines per second. 

Please keep in mind that this build is just a beta version which I rolled out in a couple days. Please write me if you find any problem or inconsistent result.

PS: if you are interested in our VB Migration Partner or our migration services, just run VB6 Bulk Analyzer on your project and then send its report from the Contact Us page.

Feedback from the beta test trenches

clock June 3, 2008 00:05

We received (and happily publish) another great feedback from one of our beta testers. The original text is in Italian, but I translated it for you here:

Thanks, CodeArchitects! And a special thank to Francesco Balena for the job he did in developing this great VB6/.NET migration tool.

Few people in this industy believed that such a product could be implemented and could have been so effective, including Microsoft who never really invested in a migration tool. Our company invested a lot of time and money on VB6 products, and we left abandoned to our destiny when VB.NET was released, together with many VB6 developers. Code Architects managed to create such a tool, thanks to their determination, perseverance, and deep knowledge of both migration techniques and VB6/VB.NET inner workings. From now on, VB6 applications *can* be migrated, at last!

We have adopted VB Migration Partner since the beginning of the beta test program, and we stressed it on large complex projects (over 110,000 lines of code) that contain both custom and 3rd-party components, ADO, intensive Windows API usage, advanced graphics, sockets, even a script compiler. We always got great results and were able to migrate our projects by just adding a few migration directives (pragmas) to teach VB Migration Partner how to behave in a few special cases.

Giampaolo Lionello
Software Development Manager
Prometeo S.p.A.: www.prometeo.com


What can I add to Giampaolo's words? I have seen their app in action and was impressed by their care for details. The most innovative detail is the presence of a custom script compiler, which allows partner vendors (and even power users) to customize every little detail of the application to fit their requirements. VB Migration Partner has been able to migrate the script compiler easily and quickly, which was quite remarkable.


Giampaolo and his team at Prometeo also provided many good pieces of advice. For example, they managed to migrate the entire data layer (about 25,000 lines) into a working VB.NET library in just a few hours. They then replaced the old VB6 data layer with the new VB.NET component and everything worked fine. There was a double jump from COM and .NET - VB6 calling VB.NET which was using ADO - yet the new data layer was only marginally slower (about 6%) than the original VB6 code. To their surprise they realized that this overhead was caused mainly by the many string concatenations inside the data layer compoment.

The obvious solution was to use a StringBuilder, but we went one step further: we added the StringBuilder6 class to our support library. This is a custom data type that looks exactly like a string (it supports the & operator) but it internally uses a StringBuilder. They were able to optimize all concatenations by just adding a few SetType pragmas. On top of that, we improved our code analysis engine to automatically flag all string concatenations inside loops and suggest which string variables could be turned into StringBuilder6 objects for highest efficiency.