VB Core – New compilation mode in Visual Studio 2010 SP1

VB Core – New compilation mode in Visual Studio 2010 SP1

Rate This
  • Comments 18

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.

·         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.

 

Leave a Comment
  • Please add 6 and 6 and type the answer here:
  • Post
  • Does this mean that XNA will finally support VB.NET?

  • I use Left() and Mid() all the time.

  • Then start using substring.

    XNA is one of the platforms that could benefit from this feature - more info to come.

  • Does this mean support for the Yield keyword?

  • No, it's unrelated to the "Yield" keyword.

    (A preview of the Yield keyword for VB was found in the "Async CTP", http://msdn.com/vstudio/async.)

  • This is great, with the exception of the My namespace. Why is it that we've been told to use / extend "My" since 2.0 was introduced, and now it's been mentioned as legacy or unneeded helper bloat?

  • Yield is a CTP for Async and the SP1 does NOT include async work.   This was simply an addition to the 4.0 functionality.  

    For "My" functionality - I'm not sure microsoft has recommended this however it was implemented to provide helpers and simplify some of the things people were trying to do.   These helpers have been removed when using this switch as many are just not applicable for these new platforms in much the same way as some of them were not applicable for other platforms.   Also as developers become more familiar with the .NET framework in general type were able to use the framework types directly.  

    That said, there is nothing stopping the user from reimplementing them in there own code just as there is nothing stopping them from reimplementing the legacy functions.   Its just that out of the box these are not implemented.  

    Its a tradeoff between how well used the features are, how much time it takes to implement and test and how it effects the final size/performance.    

  • Yield is a CTP for Async and the SP1 does NOT include async work.   This was simply an addition to the 4.0 functionality.  

    For "My" functionality - I'm not sure microsoft has recommended this however it was implemented to provide helpers and simplify some of the things people were trying to do.   These helpers have been removed when using this switch as many are just not applicable for these new platforms in much the same way as some of them were not applicable for other platforms.   Also as developers become more familiar with the .NET framework in general type were able to use the framework types directly.  

    That said, there is nothing stopping the user from reimplementing them in there own code just as there is nothing stopping them from reimplementing the legacy functions.   Its just that out of the box these are not implemented.  

    Its a tradeoff between how well used the features are, how much time it takes to implement and test and how it effects the final size/performance.    

  • This should have been done time ago (although I'd also remove the Asc and Chr functions). I've done ton of VB6 developing in the past (and I still have to do it some times), but sincerely, I don't like all the legacy support offered in VB.NET... I seriously dislike when I see .Net code using things like Left, Mid, DateDiff, etc.

  • Hector, I cannot agree more with you that we are in 2011 and .NET is a well established product.   Many of the legacy functionality was there to assist people in moving from VB1-6 to VB.NET but in reality there are not large amounts of people still doing this work.    Providing legacy functionality is still needed but this should not be to the detriment of all .NET developers.    

    Some of the My Functionality not supported is not even relevent on new platforms - examples may be My.Computer.Filesystem on platforms.  If developers still need this it can be implemented in there own assemblies.  

    There is also a move away from supporting older legacy concepts already in place - try using On Error Goto error handling in Statement Lambda's.   The language has evolved and developers should as well, so that they can take full advantage of new functionality.

  • Why on earth are functions like Left, Mid, and Right, being considered "legacy" functions. Those functions have always been a part of the "Basic" and thus VB idiom. Removing them seems to be a completely arbitrary decision. In my book, choices are a good thing.

    Personally, I've never understood why, given it's 2011, and we have 3+gz machines, that the compiler/linker can't link in only those methods that are actually used. That's something that the DOS versions of Quickbasic could do, but .NET can't. Get that right, and all this nonsense about "bloated libraries, blah blah" would go out the window. If you use a function, it's included, if not, it's not. <Sigh>

    As to the My Namespace, meh. It's convenient, but not terribly so, and if you look under the covers it's really just a big hack job. I could take it or leave it.

    And fwiw, LEFT and MID +cannot+ be simply replaced with SUBSTRING. The older style functions are much easier to use in the general case and intelligently handling things like a null string object, whereas substring and related instance methods cannot.

  • You have a good point about linking, we did consider it for VB Core, but the time and effort it would have taken us to implement it did not fit the schedule. So while I agree that these functions are very useful, we needed to draw the line somewhere on what would be included. We used the following considerations:

    1) Make the embedded code as minimal as possible

    2) Embed functionality that is core to the language, i.e. functions that the compiler knows about

    We are considering publishing the source code for portions of the VB Runtime that are not included in VB Core so users can do the linking themselves.  

    Avner Aharoni

    Program Manager VB/C# languages team

  • These functions are runtime functions for VB and not actually part of the language - look in the language spec and you will hardly find even a mention of any of them.     They are "legacy" in the respect that many of them are implemented directly in the .NET framework allowing them to be used interchangeably in different languages.   This is useful for samples in multiple languages and conversion of code.   That said there may be differences but these for the most part are small.

    Quickbasic/GW Basic/VB 1-6 had all these functions but it does not mean that improvements cannot be made.   The ommission was made to enable the platforms for VB developers without bloating the EXE too much.   This does NOT effect your existing code targeting supported platforms - only new code targeting these new platforms.   The workaround if you absolutely cannot live without these functions is to simply create your own implementation.   As Avner pointed out these are looking to be published but if you cannot wait simply use a tool like reflector to extract the function.

    I believe the bigger benefit is support for these platforms and this is a much bigger win that loosing some functionality "out the box".    If you really need this functionality whether it be My functionality, these legacy functions, etc. you can put it back in your own implementation.

    To make it clear - this does not effect the existing behaviour for existing supported platforms.   So on the desktop - My, Legacy, On error, late binding are still fully supported.

  • We understand this is only for new platforms but even calling Left and Mid "Legacy" is a worry for future VB development.

  • The fact that these functions are not part of the language specification and are implemented in the vb runtime means that you are always able to implement your own versions of them.   With the intention of Microsoft publishing these allowing you to see the implementation and extend them yourself I feel is a value add.    You will not be tied to MS implementation but can extend it with additional overloads and functionality.   Legacy is not such a bad word - look at the compatibility libraries as an example.   These are still available for use if you need them but things have moved on.   I would still consider them legacy functionality as well.

    I'm sure there are many functions in the .NET Framework that people have used in the past that get deprecated and people adapt there code to use new ways of work.     .NET is not a new platform now and almost all the functionality is contained within the framework and more easy to find examples of.   These legacy functions are simply wrapper functions around .NET functionality - there is no magic going on that can't be implemented in user implemented functions.

    Whats you worry on future VB development ?   Just look at this as enabling VB Development on more platforms not previously supported.   Is this a positive move ?.    

    Look at the other work being carried out such as Async and Iterators for a future version on VB.   This should demonstrate that VB has a very bright future along with C#.    The compilers team has a co-evolution strategy which means features should be implemented in both languages.    This VBCore functionality is part of the strategy so that you as a developer could chose you language to target more platforms.     I believe that the benefits from this far outweight the downsides.    Developers are smart people and with these new platforms which will make use of this feature there will be some limitations but these are fairly small in the big picture and for those writing .NET code this should not pose much of a problem.

Page 1 of 2 (18 items) 12