by John Browne, on Oct 21, 2015 6:00:00 AM
When I worked in the Visual C++ (now Visual Studio) group at Microsoft, one of the breakthroughs came when our fearless leader, Denis Gilbert, insisted we "eat our own dogfood." What that meant was that we would actually use Visual C++ to build and debug Visual C++. In this day and age that may seem obvious to the point of absurdity, but (this was 20 years ago) at the time the development team used standalone editors like Vi and Make files to do the build. The IDE was for marketing to use in demos...
When the dogfood mandate kicked in, and engineers had to actually use their own product for actual work, guess what? Big improvements in the product followed, particularly in the area of supporting large application code bases and projects.
The reason for me diving into the bin marked "Nostalgia" today is to point out that one of the cool things about Mobilize.Net is that we eat our own dogfood. Every day.
Because we have a large consulting services organization, we get to use our own tools on all kinds of real-world code, from actual customers. Large and small, weird and, well, more weird. You know what code looks like, and we see all of it. And because not a day goes by that someone somewhere in the company isn't using VBUC to migrate real customer code to .NET, we get a lot of great feedback about areas to improve. 
More automation means less work
With VBUC version 6.5, available today, we've continued our recent push to increase the level of automation in order to further reduce the work you have to do on your .NET code. Clearly there will always be fixups to do, because automation can only go so far moving from one platform to another. (Slight digression: there's always a tradeoff between the degree of automation and the quality/readability/maintainability of the generated code. We tend to favor better quality code.) But we've been focusing all year on getting you from migration to compiled code as quickly as possible.
If you've tried VBUC before, you should really download this version and check it out.
Consider that a migration (using VBUC) from VB6 to .NET involves several steps:
- Post-migration, getting the .NET code to compile in Visual Studio
- Replacing 3rd party components (OCXs) or using COM interop
- Identifying and resolving runtime errors
- Tuning for performance and adding functionality, refactoring into better OOP architecture, etc.
Our focus on recent releases has been on creating as much automation for step 1 above as possible. With version 6.5, we used a code base of real-world customer applications comprising 3.5 million lines of code. After running those VB6 apps through version 6.5, 99.9 percent of those 3.5 million lines of code compiled in Visual Studio. In one specific case an application (30,000 LOC) had over 2100 compile errors in version 6.4 reduced to 1 (that's right: one) with version 6.5.
As always, your mileage may vary.
Before leaving this topic, let me also point out that a couple of great improvements in automation came from investigating support cases from customers. So if you hit a snag in VBUC, please go here to submit a question to our online support forum. You may find that the question has already been answered.
2X Faster migrations
The VBUC works a lot like a compiler: it has a parser, which reads your code understanding things like syntax, comments, types, and so forth; it takes the code and builds an abstract symbol table (AST) from the source code, then creates output code according to a bunch of algorithms that are designed to re-create the intent of the original code in the new language/framework.
This takes time.
For really large applications, running a migration can take days. With this release, we've put in some improvements to speed things up. For one very large app which took 2.5 days to migrate, we reduced the time to 16 hours. That may seem excessive, but this is a migration of literally millions of lines of VB6 code. For smaller apps (say in the 400KLOC range), we are seeing on average a speed up of about 2X. Very small applications ("Hello.vbp") may not see much difference since there is a certain amount of fixed startup overhead to a migration.
Other improvements
Some other big changes in version 6.5:
- Large applications with complex references can now be resolved in the solution setup phase with much better results
- Better code readability in situations with shared files (eliminated namespace for shared files)
- Significant improvements in data access, both in terms of code quality and higher automation of mappings
- Improvements in code quality for projects migrating to VB.NET
- Miscellaneous improvements for dealing with type libraries, accessing and removing collections, converting menu items in control arrays, and more
- Certified to fully support both Visual Studio 2015 and Windows 10.
We really like hearing from our customers. If you have a question, problem, complaint, or attaboy, please drop me a line at info@mobilize.net. And of course, we not only make tools, we do migrations for people with other things on their to-do lists; if you want to talk to an engineer about your specific issues and applications, please go here.
