While most servicing releases do not include new functionality, Visual Studio 2010 SP1 introduced an important new compiler feature that enables Visual Basic to target new platforms that were not previously supported.   This was mentioned in some of the initial SP1 blog posts such as Jasonz blog.   

This is a strategic investment by Microsoft in the future of VB.  This provides VB with an increased agility in the future for new platforms to support Visual Basic.  

This blog provides more information about the feature; let me know if you have more questions.

WHAT IT IS?

The new command line option /vbruntime* (with an asterisk) will embed a reduced version of the Visual Basic runtime into the compiled assembly and therefore eliminate the dependency on the VB Runtime assembly since this assembly does not ship on all .Net platforms such as Windows Phone 7 and XNA.

The feature can be used from the VBC command line compiler or by adding an entry <VBRuntime>Embed</VBRuntime> into the .vbproj file.

In general, its intended use is only for specific project templates that target platforms that don’t ship with a VB runtime. 

WHEN SHOULD I USE IT?

The simple answer to this is you should never need to use this directly.   The feature has been implemented to allow Microsoft Partner teams to create Visual Basic project templates for platforms that previously didn’t support VB. When such VB project templates eventually become available, you as a VB developer will be able to do File>New Project for the new project types, and /vbruntime* will be used under-the-hood.   

WHAT’S INCLUDED?

The intention is to provide optimal VB experience for .Net VB users while avoiding the need to deploy to full VB runtime, thus the embedded functionality includes:

·         Conversion

·         VB specific attributes

·         Support for various VB language features such as error handling (.Net style), foreach loop and string comparison

·         A few useful constants and VB functions such as Chr and Asc

WHAT ARE ITS LIMITATIONS?

In order to avoid bloating assemblies with functionality that either is not used or no used much, some of the functionality provided in this assembly on the currently supported framework has been omitted.

& middot;         Legacy VB Functions – Such as Left, Mid.

·         Legacy Like operator

·         Old Style VB “On Error Goto Error” Handling

·         Late Binding

·         Much of the My Functionality

Many of these limitations do not apply to developers writing VB code using .Net idioms. For those trying to port existing legacy code over and use this functionality it may require a bit of rewriting to use .NET constructs such as the substring function, Try Catch exception handling and use of framework functions rather than the helper class functionality provided in the My Namespace.

The new mode is intended to be used in new platform and new project templates – but it can be used for existing templates though you may run into problems with code generation that depends on missing functionality. An example of this is Windows Forms Application with the application Framework project option checked.

COULDN’T I HAVE PREVIOUSLY DONE THIS WITH OTHER COMPILER SWITCHES?

It was previously possible to target some of these platforms with some cumbersome workarounds using the existing /vbruntime- switch.  It was not an ideal solution and required implementation of a number of additional items in order to make it work.   This new switch is a simpler more elegant approach that makes it much easier.

DOES THIS MEAN THAT I GET LESS FUNCTIONALITY THAN IF I USE C#?

From the list of limitations you will see that most of them relate to legacy VB functionality.  So for developers writing modern .NET code there should be no real difference.    The exception to this rule may be late binding / Dynamic.

In C# this was introduced in the 2010 product cycle.   If the platform that you are targeting does not include the dynamic language runtime then there is no difference as the C# dynamic feature uses this.    This is the case for many of the existing platforms that this feature is intended to be used on.   So the lack of late binding / dynamic support is consistent across both languages.

HOW DO I KNOW IT’S ACTUALLY DONE ANYTHING?

To see the effects of using this switch you can create a simple console application and compile it using the new functionality (either command line or project file).  To see the embedded use tools such as “Reflector” or ILDASM to disassemble the assembly. You’ll notice that “Microsoft.VisualBasic“ namespace was added to your assembly.

You can also see that there is no reference to VB runtime assembly in the in the referenced assembly list in your assembly header.  

WHEN SHOULD I USE THIS MYSELF? WHAT IS MICROSOFT’S RECOMMENDED BEST PRACTICE FOR USING THE FLAG?

Most users will never use it themselves directly. It’s there only for consumption by people who create project templates – i.e. mainly just for us to use here in Microsoft. The recommendation is that if you create a project template for a platform where Microsoft.VisualBasic.dll doesn’t exist, then use the flag.

HOW DOES THE RELEASED VB SUPPORT FOR WINDOWS PHONE 7 WORKS?

The release of Visual Basic support for windows phone tools 7 allows developers to create VB applications that runs on the phone even though the phone does not have VB runtime. This is done by adding to each VB application a VB Core assembly. This solution has a few issues, for example C# applications cannot reference VB class library. 

We plan to use the VB Core mode for future versions of Windows Phone tools to solve these limitations.