Compile VB.NET code without Microsoft.VisualBasic.dll

Introduction

Let's say you are developing a program using Visual Basic .NET (2003 or 2005), and you wish to make sure that your code is using "pure" .NET and is VB6 free.

Background

As you all know, Visual Basic .NET enables you to code using VB 6 legacy syntax and keywords. For example, we can use CInt, Mid, InStr etc. The implementation of the compatibility layer is at the Microsoft.VisualBasic.dll library.

Behind the scene

When compiling your program, using either the Visual Studio IDE or the vbc command line compiler, Microsoft.VisualBasic.dll is added as a reference, and there is no direct approach of removing this reference. The official (and quite not reasonable) solution to the problem is to add the -sdkpath command line option to the vbc (you cannot set this option in a VB Visual Studio project). Copy the .NET platform assemblies that are required by your project references, into a different directory, and build your program from the command line, having the -sdkpath pointing to that directory.

Behind the whole theater

There is an undocumented vbc command line option -novbruntimeref, which you can use (at your own risk :), as an alternative to -sdkpath. Adding -novbruntimeref excludes the implicit addition of the Microsoft.VisualBasic.dll reference. For example, compiling with the -novbruntimeref option will fail if you will use Mid instead of Substring.

Now, your compilation is VB6 free. And don't get me wrong, VB was a great friend of mine since VB3, and some of my best friends are ... well, you got the point.

Should I stop using the Microsoft.VisualBasic namespace?

Yes and No.

No - Productivity. If you wish to parse strings using the VB6 Mid instead of Substring, it's your call. After all, this layer was made for enabling you to import VB6 applications into .NET, seamlessly, without code changes.

Yes - Compatibility. For example, VB6 collections are 0 based for read, and -1 based for insertion. Upgraded application that use VB collections through inconsistent implementations of IList may experience some bugs.

Both points are very important. The choice is all yours.