A group blog from members of the VB team
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.
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:
· 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.
· 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.
It amazes me that the more "modern" the language gets the more like C# it resembles. I look at it the other way in that C# is incomplete, and not as rich as VB. I certinally hope that in the future we will not be forced to using a VB# type language, or have to impliment the rest of the VB functionality with add-on's, third party tools, etc. I too like the string handling in VB. .Net is combersome and not as mature as VB was in VB6. My namespace is very convienent, I always wondered why this was not available to C#, another example of VB's richness and productivity superiority over the c-like languages.
If late binding is removed then some of my programs will cease to exist
Oh, it's not our intention to remove late-binding from the language. To the contrary, we've added late-binding to C#. However both VB and C# late-binding have hard dependencies on portions of the CLR or the BCL which are not available on all platforms; especially those emerging platforms on smaller form factors where size is more limited (such as Phone).
The goal of VB Core should be seen less as an outright effort by the VB team to remove things from the language but rather to describe the minimal set of things absolutely essential and intrinsic to the language for it to be said that a given platform supports Visual Basic or that a given implementation is Visual Basic. It's still possible to say that VB exists on Windows Phone, XBox, again for example, without late-binding or the My namespace, or even the Left function. It's a lot harder to say that it exists there without the intrinsic data type conversions described in the language specification.
By demarking the core functionality of Visual Basic we're more agile to support new platforms as they arise.
It is certainly our intention that late-binding continue to be a supported function in both VB and C# on those platforms which are capable of doing so (such as the Desktop/Silverlight). In fact if you download the bits released for BUILD you can see that both VB late-binding and C# dynamic are fully functional in the even as yet unreleased Win8 Metro platform.
Finally, it's worth saying that there exists code in our own internal sources either for production or test which relies on late-binding as well. It's a convenient feature we recognize as valuable in plenty of scenarios so, like you, some of our programs would cease to exist (or become significantly less productive) were it removed entirely from the language.
Anthony D. Green
Visual Basic & C# Languages Team