Core6: "VB-Core" -- make the vb runtime optional without breaking CType &c.

[This post is part of a series, "wish-list for future versions of VB"]

IDEA: "VB-Core". Add a checkbox to the Project Properties dialog to “Embed VB runtime". With this checked then your executables and DLLs will no longer have a reference to Microsoft.VisualBasic.dll: instead they will embed a small subset of it, the minimal runtime helper functions for core language constructs like CType. You'll get a compile-time error if you try to use any runtime functionality outside the subset.

 

SCENARIO: Maybe some new partner team within Microsoft wants to make a new cut-down version of the .NET framework for their new platform. They can’t easily include Microsoft.VisualBasic.dll in their framework because (1) it has lots of references to parts of the framework that aren’t in their cut-down version, and (2) they want to keep things small. In the end it’s much hard for them to support VB that it is to support C#.

 

Note that this feature doesn't benefits VB users at all by itself. It merely enables partner teams to support VB more readily.

Note that VB users can already compile without Microsoft.VisualBasic.dll, through the /vbruntime- command line switch. But if you use things like CType() then it gives compile-time error BC35000 “Requested operation is not available”.

 

 

So what exactly is inside Microsoft.VisualBasic.dll? ...

  • Late-binding support. This is large and would not be embedded into a user's assembly; it would remain inside Microsoft.VisualBasic.dll. Indeed C# has copied this practice and left its late-binding support inside Microsoft.CSharp.dll.
  • Intrinsic language conversions. The Visual Basic language has a lot of built-in conversions that are valid even in a program with Option Strict On, for instance Dim x = CType("5", Integer). These add up to about 20k.
  • My namespace. Support for things like My.Computer.FileSystem, and for users to expand "My" through their own libraries.
  • VB6 compatibility functions. Things like FileOpen(...). These would not be embedded into a user's assembly.

 

Provisional evaluation from VB team: This is a decent idea, one that we should consider against the other decent ideas.