VB Runtime agility, Orcas and new platforms

One of the problems that we’ve run into when trying to get new platforms such as the Compact Frameworks or Silverlight to support Visual Basic is getting the VB runtime supported on the new platform. The VB runtime, besides having a bunch of user functions such as Left and MsgBox and such, contains a number of language helper functions that are required for the correct functioning of the language. For example, when you convert an Integer value into a String value, we emit a call to a helper that does the conversion for you, since there is no native IL instruction for this. The number of situations where we emit helper calls isn’t huge, but there are some core features of the language that just won’t work without them. This is why there’s been no officially supported way to remove the reference to Microsoft.VisualBasic.DLL.

More than the language, though, the problem is that the compiler won’t work without the helpers, either. Basically, the VB compiler will just crash when it fails to find a VB runtime helper. Even if you’re careful to avoid features that don’t use helpers, it still doesn’t mean you can just run without a reference to Microsoft.VisualBasic.DLL–there are still many cases where we sanity check for helpers even if we aren’t going to use them. Which means that even if you managed to figure out how to get the compiler to not reference Microsoft.VisualBasic.DLL, it was likely that lots of things aren’t going to work.

As we faced the prospect of more and more platforms starting to support .NET, we realized that we needed to do something about this situation in Orcas. So we did a feature we’ve been calling “runtime agility.” The runtime agility work basically enables new platform developers to compile without a standard reference to Microsoft.VisualBasic.DLL and we’ll only barf on missing runtime helpers if you try to use a feature that requires them. And when we do barf, we give you a nice error message telling you what helper was missing instead of just crashing. You can also redirect the VB runtime reference to another DLL if you’re building a new one for your platform. For platform developers, this means that they can more easily develop a VB runtime DLL for their platform without having to stub in a bunch of helpers that they don’t support. And, yes, if you really want to run without a VB runtime, you can now do that.

This switch is only supported on the command-line for Orcas–there’ll be no UI expression of it. The switch is “/vbruntime” and should show up, I believe, in Beta2.

13 thoughts on “VB Runtime agility, Orcas and new platforms

  1. Pingback: OPC Diary

  2. Anthony D. Green, MCPD

    Why would the VB compiler not simply use the System.Convert class or Interger.Parse to convert a string to an integer, or ToString to convert back?

    As I understood it the VBR was written in VB which makes it pure managed – shouldn’t it just work on any implementation of the CLR (minus of course those methods which call into the Win32 api)?

    Reply
  3. Rolf Bjarne Kvinge

    This is great news!

    It will certainly make a lot of things easier for a lot of people.

    It’s however somewhat counterintuitive that you have to add /vbruntime to remove it 🙂

    Reply
  4. paulvick

    Anthony: There are additional semantics that many of the language constructs supply that aren’t implemented by the CLR. Where there’s an overlap with a CLR method, we definitely use it. The problem is that almost all other CLR ports don’t include everything that’s in the desktop CLR, so we can’t just run our runtime unchanged.

    Rolf: Well, to remove it you say "/vbruntime-"…

    Reply
  5. Rolf Bjarne Kvinge

    /vbruntime- makes more sense 🙂

    Will there be a way to tell this to the compiler used inside VS (the one that compiles while editing) as well? (You do say no UI, but there are already quite a few things that can be done by editing the project file by hand, and this would be a good candidate in my opinion)

    Reply
  6. Anthony D. Green, MCPD

    Rolf, it’s funny what you can do with those msbuild files – I can actually get the project to compile netmodules into a project (build suceeds) but the IDE still flags it as a compile error – very weird how those two aren’t in sync.

    Paul, I can see that. A specific instance I encountered in my experiments with Mono is VB’s support of OnError goto. To facilitate this, as I recall, all SEH blocks also include a call to void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.ProjectData::SetProjectError(class [mscorlib]System.Exception). If you don’t use language constructs that take advantage of the Err object why emit the dependency?

    Reply
  7. Pingback: Corrado's BLogs

  8. paulvick

    It may be possible to edit the msbuild files to pass the switch directly, I’m not really sure… I’m not enough of a project system expert!

    Anthony, the problem is that it’s impossible to predict if other loaded assemblies will be relying on correct On Error behavior. We’ve considered a switch to turn off this behavior, but so far it hasn’t made it to the top of the list…

    Reply
  9. Pingback: Panopticon Central

  10. Jens Samson

    Paul,

    Please include such a switch, there isn’t a single On Error in my code, and such a switch could prevent others from using it.

    Reply
  11. John

    WHY Why why can’t we have this functionality inside the IDE???. I always avoid all the old vb calls like Len CStr Mid Collections etc.

    Reply
  12. Pingback: Anonymous

Leave a Reply