Part 3
One of the most valuable and least appreciated aspects of C# (and .NET for that matter) is the ability to utilize code written in another .NET language when you really have to. Although I mentioned in Part 1 of this series that mixed language development is unlikely to ever be a goal or even a desire on the part of a development team—due to language preferences, shared experiences, and the like—sometimes there is a body of code that is so useful (or irreplaceable) that it must be re-used in its current form. This is the case when migrating code from VB.NET to C#, as we'll see.
Last time, we looked briefly at a code fragment in VB.NET that accessed a legacy VB6 function Len() to calculate the length of a string. Rather than drop support for the legacy functions and statements, VB.NET for the most part absorbed them into the language, resulting in the capability to write brand new VB.NET code that looks very much like old-style VB6 code. Whether that is a good thing is left to the reader's judgement, but it is true that this made it much easier to ensure that VB6 applications could be upgraded (migrated) to .NET.
However, as I mentioned in Part 2 of this series, C# started with a clean slate for the most part and dropped or neglected to carry forward design ideas which had proven to be problematic in the field. So mapping VB.NET to C# requires mapping constructs in VB.NET that do not have a direct, native C# representation. In some cases (including this example), it is possible to map the VB.NET constructs to a .NET framework construct that can be used in C# (and would be more natural and likely easier to maintain). A different approach, and one that we'll consider in this issue is re-using Visual Basic "technology" inside C# itself.
What?
Yes, you read that right. It's entirely possible and perfectly acceptable in migration projects to re-use parts of VB.NET inside of C#. As it turns out it's also very easy to do. The first step is to add a reference to the Microsoft.VisualBasic assembly in the references for the C# project. This assembly contains support for a myriad of VB.NET features. In addition, the sibling assembly named Microsoft.VisualBasic.Compatibility contains support for a variety of VB6-isms that are supported in VB.NET. Once you add the assemblies to your projects, you can open the Object Browser on both of them and take a look at what they contain:
|
| Click for larger image |
In this example, I clicked on the Strings class within the Microsoft.VisualBasic namespace to see the set of VB6 string functions supported by VB.NET. To morph our VB.NET fragment to C#, we're going to use this namespace to ease the translation. Let's continue our look at how.
Here is the C# code translated from VB.NET:
string s = "Hello World"; int size = Microsoft.VisualBasic.Strings.Len(s);
We can see that the VB.NET String (actually a .NET System.String) was converted to a C# string (which in reality is also a .NET System.String). What is new and interesting is the injection of a reference to the Len() function in the VisualBasic namespace within the Strings class. This allows us to continue using the VB6-style expression syntax from within C#!
Now, of course the first thing someone in C# would likely do when confronted by this code is to change the string length calculation into a call to System.String.Length as I did in Part 2 for the VB.NET code. But consider a VB.NET project within possibly thousands of lines of code containing hundreds (or thousands) of references to these types of legacy constructs. Porting them all to native .NET framework syntax while doing the migration would greatly increase the cost of migration, potentially derailing the whole effort. Not a wise approach when budgets have to be kept and deadlines met. Not to mention that developers who never worked with VB might misunderstand the original purpose of the function, and inject coding errors.
This was a simple but common example of a translation issue between VB.NET and C#. The novice might have just "re-written" the expression and done so unnecessarily. Actually, there are scores more of these translation issues between the two languages. Next time, I'll focus on what you can do to mitigate translation problems, common problems you'll likely see and why hand translation of code is not the smartest approach.
Stay tuned.
Whether you are moving to .NET from Win32 or have been using .NET since 1.0, I encourage you to listen to .NET Cast, an Internet radio show that I host and produce for CMP Media. Hear from the people behind .NET and key experts in the industry working with it. For those of you with RSS readers, you can find the feed at http://syndication.sdmediagroup.com/feeds/public/cmp_podcast_dotnet.xml.
Mark M. Baker is the Chief of Research & Development at BNA Software located
in Washington, D.C.
Do you have a Windows development question? Send it to [email protected].