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.

Comments (3)

  1. This can be easily done with external tools: you compile as normal, then the external tool takes as input your built assembly/assemblies + MS.VB.Runtime.dll and embeds the used parts of MS.VB.Runtime.dll into your assemblies.

    Best part: it has already been implemented: http://www.mono-project.com/Linker

    No need to add extra complexity to the compiler when there are easier+better ways to do it (and this way the same tool can be used for other purposes too, it wouldn’t be VB specific).

  2. Joacim says:

    @Rolf Bjarne, maybe you should read the scenario again. Linking in the VB runtime assembly with your own assembly does not solve that senario.

  3. weitzhandler says:

    I would never want to waive the My namespace, the Like, Mid etc. operators!!