I have worked with companies that have made a long-term commitment to using VB.NET as their core development tool, and one of their biggest concerns is that they’re not writing Pure Framework code unless they use C#. They get this impression for two primary reasons. First, VB developers in the COM world were always at a disadvantage with C developers because of the limitations of the VB (6.0 and earlier) run-time implementation. They’re concerned that those limitations will carry over into the .NET world. And Microsoft isn’t helping the situation by promoting C# as the primary .NET development language.

One customer raised this issue with me, specifically asking me to help his company use VB.NET as a pure .NET language without any of the VB6 baggage. When I asked why he believed that VB.NET was not a pure language, he pointed me to a recent project that he upgraded from VB6 to .NET in which there were Imports statements pointing to Microsoft.VisualBasic and Microsoft.VisualBasic.Compatibility and the associated project references. He asked, “Why were these necessary if VB.NET is a first-class language in the .NET environment?” To answer his question and to provide good architectural recommendations for using VB.NET in your development shop, I’ll explain how Microsoft implemented the VB language for the .NET platform.

The core VB DLLs
The core VB language is built into the .NET Framework in the same manner as the C# language. The key difference is that Microsoft has included two additional support libraries for Visual Basic developers. The first, Microsoft.VisualBasic, is a core part of the .NET redistribution and maps common VB syntax to framework equivalents. In fact, some VB functions (particularly conversion) offer better performance than calling native CLR objects. For instance, CInt() is better than calling the Convert object. Additionally, some VB functions do extra work that you’d have to do yourself. For example, CStr() handles locale information in the conversion, so you don’t have to.

Also, this library provides access to common environment constants that VB developers have learned to use like vbCrLf. You create the same constants by using either the System.Environment.Newline method or System.Convert.ToChar(13) & System.Convert.ToChar(10). Constants like vbCrLf map directly to underlying framework calls and should have no impact on the performance. In the case of vbCrLf, the compiler optimizes it to a single string; if it is a variable, it maps directly to \r\n, which translates to a carriage return. Using statements that map directly to underlying framework calls like msgbox, which maps directly to the .NET Framework MessageBox, have little or no effect on performance since the underlying IL will be basically the same.

There are some VB6 features like InputBox, control arrays, and ADO support that have no direct framework equivalents. For these, Microsoft provides another library, the Microsoft.VisualBasic.Compatibility, which is for VB6 compatibility and should never be used if you’re not upgrading. This library contains support for control arrays, environment functions, and font conversions. Microsoft provides an additional library (Microsoft.VisualBasic.Compatibility.Data) that includes ADO objects, interfaces, and methods for fully connected operations using ADO as the data interface. If you want any indication of whether you should invest time in learning or using its functions, you should heed this warning from the VS.NET help file:

“Caution: It is not recommended that you use the VisualBasic.Compatibility namespace for new development in Visual Basic .NET. This namespace may not be supported in future versions of Visual Basic. Use equivalent functions or objects from other .NET namespaces instead.”

This is where you should focus your efforts on eliminating whatever VB6 baggage your programs or developer habits may carry forward into VB.NET. There are better framework options for performing the same functions provided by the compatibility library. You don’t have to switch to C# and lose years of investment in VB training and practices to take advantage of the new .NET Framework. In fact, I recommend to my customers that they avoid using the upgrade wizard at all (which adds the compatibility library to the .NET projects it creates) and focus instead on architecting their applications to complete the .NET Framework rather than attempting to upgrade to VB.NET.

True .NET functions
Microsoft.VisualBasic is part of the implementation of the VB language itself. The functions are true .NET and were not added solely for compatibility with earlier versions of Visual Basic. Leaving the project Imports statement in a VS.NET project has no impact on the performance of a VB.NET application. Basically, it tells the compiler where to find compatibility code if the program attempts to use it.

The .NET Framework will always have the Microsoft.VisualBasic namespace, and it will always be in the redistribution. In the words of one of the members of the VB.NET product team, “You’re not gaining anything by removing Microsoft.VisualBasic.dll. The functions the DLL exposes are not VB6 baggage; they are fully implemented in VB.NET, familiar to VB programmers, and forward compatible. Lastly, if you reuse code from any VB samples, they will use these functions. Removing the DLL does not make the application more pure; it means you are removing helpful classes.”