One of our clients wanted to change the CreateObject function migration for a function of their own. So they wanted all cases like:
Dim x As Object
Set x = CreateObject("Excel.Application")
To be migrated to something like:
Excel.Application x = (Excel.Application) Utils.MyCreateObject("Excel.Application", "");
Our migratio vb6migration tool provides a new cool feature called CustomMaps. This feature allows you to provide some simple but useful changes to the way things get migrated.
For this case follow these steps:
1. Open the Visual Basic Upgrade Companion.
2. In the Tools Menu choose:
3. Create a new CustomMaps File and an an entry like the following:
Notice the Source name is VBA.Interaction.CreateObject. To find out this name you can look in your VB6 IDE, right click on the CreateObject and select goto Definition.
and for the target name just put the implementation that you what, for example you can write a function like:
class Utils
{
public static object MyCreateObject(string className,params object[] ignoreRestParams)
{
return Activator.CreateInstance(Type.GetType(className));
}
}
and set the SourceName to Utils.MyCreateObject (or NameSpace.Utils.MyCreateObject to use the fully qualified name). You just need to set the New Reference Name column because we will not change the definition of the function.
This post shows a way to calculate the number of weeks.
Remember that this calculation is culture-dependant
For example the GetWeekOfYear methods requires a criteria to determine
how to determine the first week and which day to consider as FirstDayOfWeek for more info see here:
CalendarWeekRule.FirstDay
Supported by the .NET Compact Framework.
Indicates that the first week of the year starts on the first day of the year and ends before the following designated first day of the week. The value is 0.
CalendarWeekRule.FirstFourDayWeek
Indicates that the first week of the year is the first week with four or more days before the designated first day of the week. The value is 2.
CalendarWeekRule.FirstFullWeek
Indicates that the first week of the year begins on the first occurrence of the designated first day of the week on or after the first day of the year. The value is 1.
Sample Code
Dim x As Date
Dim currentCulture As System.Globalization.CultureInfo
currentCulture = CultureInfo.CurrentCulture
Dim weekNum = currentCulture.Calendar.GetWeekOfYear(x, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday)
On Wednesday April 15th 2009 Avanade and ArtinSoft will host a webinar on how to quickly and cost effectively renew your Visual Basic 6 applications.
Here’s an excerpt from the invitation:
“Don’t miss this chance to learn more about VBUC and other cost effective migration options, including:
• Which migration strategy works best for you (complete, partial,
coexistent, partial development)
• How to reduce project risk, costs, and time to market
• How to guarantee business continuity by preserving knowledge
invested in legacy applications“
You can RSVP and make sure you don’t forget to attend.
If you have your ASP.NET application for example in c:\inetpub\wwwroot\WebApplication1 and you want to programmatically get that path just use something like:
string AppPath = Request.PhysicalApplicationPath;
Here is a summary of some recent case studies that we have produced with our customers.
The message is common: Visual Basic 6 to C# migrations are an excellent alternative that saves time and money when you need to move your application to .NET.
HSI
This Texas-based company provides geo-navigation solutions for the horizontal drilling industry, and when the end of official support for the VB6 development environment was announced, they turned to ArtinSoft to migrate their LatNav application from VB6 to C# on a turn-key basis, using a slightly customized version of the Visual Basic Upgrade Companion.
“Utilizing the Visual Basic Upgrade Companion saved us about one year of development and $160,000. This conversion will allow us to leapfrog well in front of our competition” -- Ken Bowdon - HSI founder
Read the full HSI case study.
MDA
After discarding a manual rewrite and the Upgrade Wizard, MDA –a software services provider for the real estate sector– settled for ArtinSoft’s Visual Basic Upgrade Companion tool, with which RDO was transformed to ADO.NET, third party controls were converted to native .NET controls, Component One’s True DB grid was upgraded to the latest version of that component, and coding standards that were common place when developing in Visual Basic 6.0 were also migrated to equivalents in VB.NET.
“We looked at different options, like a rewrite and the Upgrade Wizard. The UW couldn’t cater for our needs, especially since we were going from RDO to ADO.NET. A rewrite would have been about a five-year project for us, and possibly in the region of US$500,000. Using the Visual Basic Upgrade Companion represented an estimated saving for the project of about 3 years and US$300,000”. -- Rodger Beadle – Technical Director, MDA
Read the full MDA case study.
Vertex
Vertex, a leading global BPO and customer management outsourcing company, managed to ensure compliance and business continuity by upgrading not one, but two mission-critical applications from VB to .NET using a customized version of the Visual Basic Upgrade Companion (VBUC). These case studies underscore the joint efforts made by both companies, which proved to be decisive to accomplish the goal of having both migrated applications up and running within some serious time constrains.
"ArtinSoft has been an excellent company to work with. They have been responsive to requests from Vertex to change their processes in order to accommodate the way in which we work. They have provided us with daily updates throughout the migration life cycle and have worked in partnership with Vertex to resolve any issues that have arisen in a pragmatic and expedient manner." -- Sue Craig - Senior Project Manager, Vertex
Read the full Vertex Omiga Case Study.
Read the full Vertex Supervisor Case Study.
Banamex / Citigroup
Learn how Banamex, one of the most widely recognized financial institutions in Latin America and purchased by Citigroup in 2001, was able to migrate over 5 million lines of code from VB6 and ASP to C# and ASP.NET using ArtinSoft’s Visual Basic Upgrade Companion, in compliance with Citigroup’s corporate policies for quality assurance and information security. The project also included the creation of an effective collaboration environment and the implementation of highly advanced security tactics in order to guarantee full confidentiality in data handling.
Read the full Banamex/Citigroup Case Study.
At some point in time companies decide they want to leave a certain platform. Let’s not focus on the reasons why they decide to move but on HOW to move instead. Companies reach the decision to move on their own timetable.
Once you have decided that you want to move away from VB6 then ArtinSoft comes into play. The purpose of my blog is to show that there is a way out that is good, fast and cost-effective. Compared to what? You might ask, let’s see.
Once you decide to move (let me be clear, you made the decision to move, then the rest of the discussion applies) you have to assess your applications and make a decision on HOW to move them one by one.
There are three axes along which we recommend our customers to make the analysis:
- How unique is the functionality to your business? For example, if you have a general ledger that does not have any particular features for your business, if you have a “me too” app that does not give you an advantage over your competitors, well, you should consider just buying a package and replace it.
- How good is the technical quality of your source code? Have you followed best practices in VB? Is your code maintainable by a third party? (Can they understand it?) If the answer is no then migrating it to a new language is not going to improve this situation. Consider a rewrite.
- How fast is the functionality changing to meet business goals? Is the business process it supports fixed? Do you anticipate that very minimal changes will happen before retirement? Then you should just leave it as is (one caveat here, in some industries because of regulatory issues you might still make sure you are on a fully supported platform even if the application does not change).
Now, if you have an application that provides you a business advantage, that is of good technical quality and that needs to adapt to new business challenges, then you have a good candidate for a migration.
For applications with the above characteristics, why is a migration better than a rewrite?
- Cost: when we look at cost there are several dimensions.
- Cost of the actual migration process: An automatic migration to functional equivalence can be done with about 20% of the cost of a rewrite. Most of that cost is testing and fine tuning of the application to the new platform.
- Training of end users: Since the application is functionally equivalent it is not necessary to retrain end-users. With a rewrite, chances are that the output is not going to be functionally equivalent unless you follow an algorithmic approach just like an automatic migration and therefore end users need a retraining. In addition to the actual retraining cost (which can be enormous – e.g. we worked with a customer whose system required a 6 weeks training time, for 3000 users. An application replacement or rewrite would have started with that hole in front of them) but the opportunity cost. New software, new mistakes, how does that impact the business continuity?
- Time: An automatic migration process can also be done in about 20% of a rewrite. This means that you can free up resources much faster to actually build new functionality that the business requires instead of attempting to replicate functionality that already works.
- Quality: An automatic migration does not fundamentally change the architecture of the original application (even if certain aspects like data access and some pieces of GUI architecture do change). The question is: do you really need to change the architecture for the whole application? Probably not. You might need to change the architecture for certain processes. The code that is generated by ArtinSoft is completely ready for evolution. No strange variable names, all comments preservation, no restructuring of the code, etc. Even if in the worst case scenario you need to rewrite a certain piece of the application it is always a fraction of the total cost.
Comments?
In the VB6 world it was very common to use “Resizer” OCXs that you just put on your forms and that they handle all the proportional resizing needed if you changed your form.
It was very simple and easy.
However when I started looking for something like that in .NET it was quite hard to find. So finally I got to ComponentSource and found some alternatives and I evaluated them:
Component | Vendor | Pricing | URL |
Component One Sizer For .NET | Component ONE | I think you have to buy the Component One Studio. That’s $800 ($1000 with more support) and I think is one license per developer, runtime-free | http://www.componentone.com/SuperProducts/StudioWinForms/ |
.NET Forms Resize | Softgroup | 380$ per developer from ComponentSource if you buy directly from them you can get the component for 180$ Each copy is licensed on a per developer basis. A developer may use the license on multiple CPUs as long as they are not used concurrently nor used by another developer. Run-time royalty free. | http://www.soft-group.it/net/index.php?c=3a&id=11
|
Resize OCX/.NET | Larcom and Young | 95$-100$ per license one license per developer, runtime-free | http://www.lyoung.com/ |
All of them seem to work. So it really up to your company preferences, budget and the level of support you desire. I haven't made tests like how it behaves if you have thirdparty components or activex ??? maybe I'll review that later.
Most of our clients come from a medium-size to a big enterprise level. In these scenarios is very common to have different department using different technologies to solve their business needs.
These different technologies can be on a very homogeneous platform like .NET where you can easily interact between your VB.NET and C# assemblies, or they could be on differente technologies like ASP, Classic VB, C++, or Powerbuilder.
This post is about PowerBuilder, and in order to interact with PowerBuilder I think the easiest way is to expose your assemblies thru COM Interop.
So if there is some .NET functionality that you want to expose to PowerBuilder you just need to expose that functionality with a class in a ClassLibrary project with COM attributes.
Let’s begin with a simple program to show how to comunicate Powerbuilder with C#.
NOTE: If you don’t have Powerbuilder you can get a trial version from: http://www.sybase.com/detail?id=1052162
- Open Microsoft Visual Studio
- On the File Menu, choose the New option, and in the File submenu choose Project….
Figure 1. Visual Studio File Menu. Choosing the option for a new project
- When you choose that option a dialog window will shown with the available options for new projects. In the option for C# Projects choose “Class Library”
Figure 2. New Project dialog window
You must introduce the new project name, location and solution name. Type something like ClassLibrary1, D:\PowerBuilder, ClassLibrary1.
1. When you finish creating your project you will have a code file called Class1.cs.
2. Change that code for something like :
using System;
using System.Collections.Generic;
using System.Text;
namespace SimpleClass
{
public class Class1
{
public int AddTenToParameter(int param1)
{
return param1 + 10;
}
public void SayHi()
{
System.Windows.Forms.MessageBox.Show("Hello World!");
}
public String GiveMeDate()
{
return DateTime.Now.ToLongDateString();
}
}
}
This will allow to test things like parameter passing, using different return types like strings or integers. But Before you continue you must add a reference to System.Windows.Forms to be able to use the MessageBox.
Figure 3. Adding a reference
Figure 3. Reference to System.Windows.Forms
3. Right click on the solution file and select properties:
Figure 4. Option to change project properties
4. Select the Register for COM Interop checkbox
Figure 5. Project properties window
5. Return to Class1.cs code file
6. Add an using statement after the existing using lines on Class1.cs file:
using System.Runtime.InteropServices;
7. Add the following attributes to the class:
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]
[ProgId("ClassLibrary1.Class1")]
Note: the ProgId is very important, because these value will be use in PB to comunicate with the this code
8. Now you must edit the AssemblyInfo.cs
Figure 6. AssemblyInfo.cs File
Now make sure to establish the COM settings in this file with statements like the following:
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(true)]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("69efac5b-d887-40f4-a7e9-2721ac3c1598")]
The Guid is also very important, because this is used to differentiate this component and it must be unique.
To generate a new GUID you can got to the Tools Menu and choose the option Create GUID
Figure 7. Option menu to create a GUID
In the Create Guid dialog box, choose the fourth option and press Copy to put the contents on the Clipboard. Later, copy that value in the GUID attribute but remove the “{“ y “}”.
Now we are set. You only need to build the solution and the DLL. The build process with register the COM component.
If you will use the component on another computer you need to create an instalation program.
Using your program from Powerbuilder
Using your program from Powerbuilder is very easy. You just need code like the following:
Figure 8. PB Code to call a C# class thru COM
When you execute this program you will have 3 messageboxes :
- Hello World!
- 30
- Monday, March 02, 2009 (this message will change depending of the day, locale and regional settings)
Creating an instalation program
- Right click the solution and in the context menu choose Add and then new project.
Figure 9. Context Menu to add a new project
On the dialog box for Add New projec, look for the Other Project Types section and the choose Setup Project.
Figure 10. Creating a setup project
In this dialog bos indicate the name and location of the setup project. For example Setup1 and D:\Powerbuilder\ClassLibrary1.
Later, add a project to the setup program. To do that rigth click on the setup project and select Add, and in the submenu choose Project Output.
Figure 11. Adding a project to the setup project.
A dialog box will be shown with a combo that allow you to select the proyects in the solution. Choose ClassLibrary1 and press OK.
Figure 12. Adding project output to the setup project.
When you build this instalation program two files will be produced:
Release
D:\PowerBuilder\ClassLibrary1\Setup1\Release\Setup.exe
D:\PowerBuilder\ClassLibrary1\Setup1\Release\Setup1.msi
Debug
D:\PowerBuilder\ClassLibrary1\Setup1\Debug\Setup.exe
D:\PowerBuilder\ClassLibrary1\Setup1\Debug\Setup1.msi
When you run the instalation program, this program will handle the instalation of the .NET component and the COM registration.
This week Microsoft updated its support statement for Visual Basic 6.0 to include the upcoming Windows 7. Even though the original idea was to not support VB6 in Windows 7, given the outstanding demand, the runtime WILL BE included in the OS.
To summarize, the support status of the different Visual Basic 6.0 components is:
- Visual Basic 6.0 IDE: Unsupported as of April 8, 2008.
- Visual Basic 6.0 Runtime: Supported for the lifetime of Windows Vista, Server 2008 and 7. *This is the big change in the Support Statement*.
- Visual Basic 6.0 Runtime Extended Files: The supported versions are here.
Even though the runtime components will be supported in Windows 7, it is important to consider the implications of the IDE not being supported (as I described in this post). There are also additional advantages of moving to .NET such as 64-bit support (VB6 apps are 32-bit only) and all the productivity, maintainability and deployment gains provided by the platform.
A while ago, I blogged on the benefits of migrating from VB to .NET,
based on an analysis that one of our customers did before engaging in the
upgrade process. They had about 124
applications, for a total of more than 5
million lines of VB6 and ASP code that needed to be migrated to C# and ASP.NET to comply with corporate policies, while
they expected more than US$40M of accumulated benefits in 5 years as a result
of this investment.
Well, the migration was completed some time ago, and they’ve
been including several other applications during the process, and we’ve just
released the case study for the original
engagement. The customer is Banamex, a
leading Mexican bank, part of Citigroup, and the project implied an
unparalleled methodology for collaboration between customer and provider teams,
taking into account that Citigroup’s information security policies required to
establish an appropriate mechanism for protection of sensitive data. Not to mention
extremely tight deadlines!
The business logic and functionality had to remain intact, and dependencies
with non-authorized providers, like proprietary runtimes, were just out of the
question, and using ArtinSoft’s
Visual Basic Upgrade Companion allowed reaching 100%
functional equivalence on time and on budget. You can read the complete Banamex/Citigroup case study
here.
This week we published a new case study on the migration we performed for Banamex, part of Citigroup and one of the largest Mexican banks. In this project we migrated 124 Visual Basic 6.0 and ASP applications from different divisions of the bank to C# and ASP.NET. All in all, we migrated over 5 MILLION LINES OF VB6 AND ASP CODE. This is the largest VB6 to .NET migration we’ve done so far, it was a huge success story – so much that we are now working on the migration of some other applications that weren’t originally included in the scope of the project.
You can read the details here.
We’ve just released a new case study
that shows how one of our customers saved lots of time and money by using our Visual Basic Upgrade Companion tool
to migrate its flagship application from VB to .NET. Based in South Africa, MDA Property Systems provides software solutions to the real state
sector. Its MDA Property Manager application is a comprehensive package for
rent collection, lease management, facilities management, integrated property
accounting and asset management, employed by more than 1800 users across 250
companies. With more than 600,000 lines
of VB6 code it encapsulated decades of business knowledge, so MDA licensed
our tool to perform the conversion to VB.NET with minimal risk and using their
own internal resources, after discarding a manual rewrite and the Upgrade
Wizard
Also, it was very important for MDA to use the newest
technology instead of just being able to run Visual Basic 6 style code inside
the .NET Environment, and using ArtinSoft’s Visual Basic Upgrade Companion
guaranteed that they will be getting native
.NET code, without any ties to third-party runtimes. RDO was transformed to
ADO.NET, third party controls were converted to native .Net controls, Component
One’s True DB grid was upgraded to the latest version of that component, and
coding standards that were common place when developing in Visual Basic 6.0
were also migrated to equivalents in VB.NET. It allowed MDA to save on valuable
resources: total savings for this
project were more than 3 years of development time and US$300,000, and they
are now ready to start taking advantage of compelling new features that will
extend the technological life of its product.
Read the complete MDA case study here
Danish magazine Version2 published an interesting article last week on VB6 migrations: http://www.version2.dk/artikel/9908-saadan-flyttes-milliarder-af-kodelinjer-fra-vb6#forum_post_anchor .
Microsoft is finally waving goodbye to Visual Basic Version 6. Its successor, VB.Net, is not backward compatible, but the company Artinsoft from Costa Rica can help with a translation machine.
By Tania Andersen, Wednesday 11 February 2009
This article really shows momentum in northern Europe.
Enjoy!
My good friend Jafet, was recently dealing with an interesting bug in Visual Studio.
He created a simple Visual Studio Project that had just an interface that he exposed thru COM. He’s intention was to compile the Class Library and use the TLB file in other projects, but after building the solution he found out that there was no TLB file generated.
After some tests he finally found out that Visual Studio does not generates a TLB if there are not classes in the Project. So your options are, add a dummy class to your project or invoke the TLB tool from the command line.
:)
A quick post to let you all know that we now have a trial available for download of the Visual Basic Upgrade Companion Developer Edition. To obtain the trial you need to fill in your information here, and we will email you the download link and the necessary licensing information to activate the trial.
The trial will allow you to migrate up to 2,000 lines of code simultaneously, and has a limit of 10,000 lines of code total – which means that every time you migrate some code, the amount of lines you migrated are discounted from the 10,000 total.
So don’t wait and download the VBUC DE trial now!
Remember that you can also request a trial for the Enterprise Edition of the Visual Basic Upgrade Companion at this page. You will need to run the Assessment Tool first, and based on the results we will send you a custom trial for a portion of your application.
Several times I’ve mentioned the Type Inference feature of the Visual Basic Upgrade Companion. The main objective of the component that we call the “Typer” was to eliminate Upgrade Issue 1037 (Couldn't resolve default property of object ‘x’) that appeared then the VBUC wasn’t able to correctly determine the data type of a variable and consequently couldn’t resolve its default property.
Even though dealing with EWI 1037 was the design goal, having a typing mechanism in the VBUC allowed us to improve a great deal of transformations. One particular feature that benefitted from it was the migration of VB6 Enums. To illustrate this, let’s look at an example.
First, let’s see some VB6 code (doesn’t really do much except use Enums):
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim enumUsage As Integer
13:
14: Public Sub MyMethod()
15: enumUsage = EnumValue1
16: enumUsage = 4
17: If enumUsage = EnumValue4 Then
18: enumUsage = EnumValue7
19: End If
20: If enumUsage = 7 Then
21: enumUsage = 5
22: End If
23: End Sub
After running the code through the VB Upgrade Companion we get this:
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim EnumUsage As Myenum
13:
14: Public Sub MyMethod()
15: EnumUsage = Myenum.EnumValue1
16: EnumUsage = Myenum.EnumValue4
17: If EnumUsage = Myenum.EnumValue4 Then
18: EnumUsage = Myenum.EnumValue7
19: End If
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
22: End If
23: End Sub
The VBUC performs some very subtle transformations to improve the quality of the generated code. Let’s look at them in detail:
First of all, the usage pattern for the variable EnumUsage is analyzed by the Typer, and it determines that it is always used to store a value of the Myenum Enum. Thus, it infers that the correct data type should be Myenum instead of Integer, as seen in line 12:
12: Dim EnumUsage As Myenum
Since the Typer keeps track of the different ways in which a variable is used, and of the values that are assigned to it, it provides information to the VBUC so it can replace the assigned values with the corresponding enumeration. This applies even for comparisons – the code is translated from:
16: enumUsage = 4
...
20: If enumUsage = 7 Then
21: enumUsage = 5
to (notice the if in line 20):
16: EnumUsage = Myenum.EnumValue4
...
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
This is just one of the features that we have worked on over time to improve the quality of the code generated by the VB Upgrade Companion. It was built on top of the functionality provided by the Typer, and works with both VB6 built-in and user-declared enumerations. As shown in the example, this makes the code easier to maintain, and even looks as if it was written originally in .NET. :)
I know this is completely off-topic to what I normally blog about, but I’ve been having problems this past couple of days when trying to checkout a document from SharePoint using Internet Explorer 7. It crashes every single time – which has been a very frustrating experience, to say the least. I have no idea what caused it to (mis)behave this way. Anyway, turns out the fix was incredibly easy:
- Close all IE7 Windows
- Run Microsoft Office Diagnostics from Start->Programs->Microsoft Office->Microsoft Office Tools
- Click on Run Diagnostics, wait a few minutes, and you should get a dialog saying that 1 repair was performed:
- Continue using SharePoint normally
FYI, I am using MS Office 2003 and Windows SharePoint Services 3.0.
As a Visual Basic 6.0 developer you may want to become yourself familiar with the .NET platform before putting it into production (and making the corresponding investments). In this blog post I wanted to give some pointers to commonly used resources that can help you in that regard.
To run one of the latest Microsoft operating systems you can take advantage of the VHD Test Drive program that I blogged about some time ago. Through this program you have access to a large number of OS configurations that you can try out for a limited time. The ones I would recommend to get started are the Windows Vista 30-Day Eval VHD, the Windows Server 2008 Evaluation, and the Microsoft Windows Server 2003 R2 Enterprise Edition VHD. Remember you need either Virtual PC, Virtual Server or Hyper-V in order to run the virtual machines.
You’ll also need to install Visual Studio 2008, and for this you can either install the Express Editions (which have some limitations, but are free), or a 90-day trial version of Visual Studio 2008 Professional Edition or Visual Studio Team System 2008 Team Suite. Another alternative is to download a full virtual machine with Visual Studio Team System 2008 Team Foundation Server installed.
Also, to get familiar with specific .NET features, you can take advantage of the free e-book offer and the additional content currently up at Microsoft Visual Studio 2008 Learning Portal.
Because of some queries we’ve had in the past few days, I think it is time to revisit the differences between the Upgrade Wizard that ships with Visual Studio .NET (2003,2005 & 2008) and the Visual Basic Upgrade Companion (VBUC). The VBUC is a different product, with very different capabilities than the Upgrade Wizard. We have a detailed comparison over at the Visual Basic Upgrade Companion vs. Upgrade Wizard page, but here is a brief overview of the main differences:
- C# Generation: The Visual Basic Upgrade Companion is able to generate C# directly from the Visual Basic 6.0 source code, as an alternative to Visual Basic .NET.
- Structured Error Handling: The Visual Basic Upgrade Companion includes features to remove unstructured “spaghetti” code and replace it with structured flow control statements in .NET. All unused labels are removed from the resulting code. Plus the most commonly used “On Error ” patterns are currently recognized and replaced by the tool. This is important for C# migrations, as it ONLY supports structured error handling.
- .NET Native Libraries: Instead of upgrading VB6 code using the Visual Basic Compatibility Libraries like the Upgrade Wizard does, the Visual Basic Upgrade Companion promotes the use of .NET native libraries whenever possible.
- Type Inference: The VBUC contains a typing system that accurately assigns correct .NET data types to existing VB6 variables, functions, fields, parameters, etc
- Stub generation: To ease the compilation process, the Visual Basic Upgrade Companion generates an empty declaration (stub) in a stub-dedicated source code file and into the converted project for each library element which occurs in the original application and does not have an equivalent in .NET. All the references to these not-converted elements are translated into references to their corresponding stub declarations. This strategy does not fully resolve the lack of .NET equivalent elements, since the stubs will require manual implementation, but, it saves an important amount of time during the manual changes stage.
- Code quality enhancements: The VBUC generates higher quality code with more mature and exact transformations. These transformations include data type enhancements and grammar pattern transformations and detailed code improvements. A detailed explanation of these transformations can be found on the VBUC vs. UW page.
- Multi-Project Conversion: The Upgrade Wizard is able to convert one single VB6 project file (*.vbp) at a time. Hence, if the user wants to upgrade a complex VB6 application with this tool, several considerations must be taken in order to accomplish full functional equivalence. The Visual Basic Upgrade Companion allows the conversion of multiple Visual Basic 6.0 projects. It performs a separation between the pre-processing and migration stages in order to fix problems like the use of by-ref parameters, interfaces, renaming and typing among the different projects. The pre-processor environment solves the references among projects and simplifies the overall migration process.
- .NET Enumerations: Another important Visual Basic Upgrade Companion feature, absent in the Upgrade Wizard, is the replacement of numeric literals assigned to several control properties with .NET enumeration equivalents when possible, so that the generated Visual Basic .NET code is more legible and maintainable.
- 3rd Party Library Extensibility*: The VBUC can be customized to convert any third party library to its native .NET equivalent. It ships with support for several libraries out of the box, which are detailed in the VBUC vs. VBUW document.
- Legacy Data Access to NET*: The VBUC upgrades the legacy data access models (ADO, RDO, DAO, ADOR) to .NET equivalents, employing special transformation rules and helper classes (for some specific source/target combinations). On the other hand, the UW generates a target application that still uses those legacy data access models to communicate with the database via COM Interop wrapper calls.
- Custom Maps*: The Visual Basic Upgrade Companion Custom Maps extensibility, allows the user to upgrade their non-supported libraries and controls using a simple set of user-defined transformations.
- User declarations advanced refactoring*: The Visual Basic Upgrade Companion manages all the user declarations to perform tasks such
as using standard Naming Conventions for the .NET languages and recognizing conflictive user-declaration names to assign new denominations (including all of its references).These tasks improve the resulting source code readability and hasten the manual change stage.
- COM class exposure*: When this optional feature is enabled, the Visual Basic Upgrade Companion will generate attributes for the COM-exposed classes and their members, in order to keep the resulting assemblies exposed through a COM interface. This enables the resulting components to be called from other non-managed components via COM.
Make sure you download the PDF on the Visual Basic Upgrade Companion vs. Upgrade Wizard page for additional details. Items marked with * are ONLY available in the Visual Basic Upgrade Companion (VBUC), and are not available in the VBUC Developer Edition.
One of the key features of the Visual Basic Upgrade Companion (one that is not present in the Developer Edition, BTW) is that it’s functionality can be customized and extended. By doing this, developers working on a migration can have the VBUC do as much of the work as possible for them, minimizing the manual work and producing a higher quality product that satisfy both the developer’s and end user’s expectations. Performing repetitive changes to, for example, replace the data access components from VB6 (ADO/RDO/DAO) with native .NET data access (ADO.NET), is better done by the VBUC at migration time. This also applies to particular programming patterns used by organizations that need to be replaced by .NET-native patterns, and to coding conventions that vary between VB6 and .NET languages.
The Visual Basic Upgrade Companion includes three mechanisms to customize the generated code: Migration Profiles, Custom Maps and Additional Customizations.
Migration Profiles
A new feature that was introduced in version 2.0 of the Visual Basic Upgrade Companion, it gives end users control over which features and transformations to use for a particular migration, by using the concept of Migration Profiles. These profiles provide two types of rules that can be switched on/off. The first type, Code Conversion Rules, that deal with patterns applied to the code, such as generating structure error handling (try…catch) from On Error…Goto statements or applying commonly used naming conventions to the code. The second type is called Component Maps, and deal with translations from from one ActiveX component, such as a status bar or a grid, to a native version of the component.
Profiles are managed through the Profile Maintenance screen:
Custom Maps
The Visual Basic Upgrade Companion includes a “mapping” mechanism that allow end-users of the tool to define the transformation of one element of a library used in the VB6 code to a member of an assembly in .NET. This allows a migration team to identify and implement time-saving transformations, and, when combined with the implementation of an adapter for the .NET component, can speed up the migration process dramatically.
The Mappings are defined through a GUI editor launched from within the VBUC itself:
Once the mappings are defined, they can be switched on and off in the migration through the Migration Profile Maintenance Window:
Additional Customizations
ArtinSoft’s VBUC development team can also include additional complex rules in the VBUC, including customizations for items such as error handling patterns, architectural modifications, and others. These customizations also include mapping COM controls to in-house libraries, or force in-house naming conventions. This was a decision point for one of clients in the United Kingdom, Vertex Financial Services, as documented in the Vertex Omiga case study:
“Vertex decided to migrate the Omiga application to C# using a customized version of the Visual Basic Upgrade Companion, a tool developed by ArtinSoft based on artificial intelligence technology. ArtinSoft was highly recommended by Microsoft UK, and the customization of this migration tool enabled Vertex to automatically convert coding patterns and meet its preferred standards.”
These type of customizations require some modifications to the VBUC that can only be performed by ArtinSoft’s in-house team. It is a very valuable option that allows companies to get a an end product which furthers increases the return on investment from the migration.