A group blog from members of the VB team
For development of windows phone applications a new feature was added to the Visual Basic compiler known as VB Core. This is a reduced version of the runtime designed to allow development for a broader variety of platforms without incurring the larger penalty of having a full VB runtime containing non-supported or older VB6 legacy functionality which are now implemented as part of the framework itself. However this results in some features not being supported on this platform such as Late binding, My functionality and somelegacy VB functions. You may not be targeting WP7 yet but this reduced runtime is also being incorporated into other target platforms such as Portable Class Libraries.
For many developers who have been using only VB.Net this may not be an issue as they would be familiar with the .NET framework functionality which is typically what is shown in samples and example code that is translated from C#. WP7 is a new platform and much of the code written for this platform is new as well. However, if you have some legacy code that you want to use on this platform and that code uses some of functionality not supported by VB Core, it is possible to create your own implementations to reinstate this functionality
(DISCLAIMER:This would be your own implementation of this functionality and you assume all risk and responsibility for maintaining it and any consequent increase in assembly size. Microsoft assumes no responsibility for the quality or accuracy of your implementation. Use this technique at your own risk).
Remember, some of this functionality was left out because it may not be applicable to the platform. An example of this is the My.Computer.FileSystem functionality because the platform utilizes a different form of storage known as Isolated Storage. But there is no reason you couldn’t create your own implementation of My helper functions.
We have created a simple example showing how to reinstate some of the functionality which is not included in VB Core. Examples include Left, Right and Mid functionality.
How do you find the code to create your own implementations of these functions?The source for the VB Runtime is and other assemblies are publically available, so you can see how these functions are implemented.
You can then choose to either include this code directly in your application or create a simple class library which you can then reference from your projects to ensure that you can use the specific functions you require that are not included in VB Core. You may want to clean up the implementation a little as there is some throwback code related to VB6 which may no longer be applicable.
The project is designed to show you have to add back missing functionality – if you really can’t life without functions such as Left, Mid, Right. The sample is designed to show you how you can put back small bits for VB runtime functionality left out of VB if you absolutely need to, but the recommended course of action would be to use existing framework functionality when targeting these new platforms using the VBCore functionality.
Why not get people to start using the .net method of doing things, that are support by mscorelib? LEFT, RIGHT, MID stink of old school VB6.
Can we get a compiler switch that flags vb only feature usage so that we can ensure our applications only use what is avaialbe to both C# and VB?
As the article said - if you can't live without this stuff then here's how to put it back in. I wouldnt advocate this as an approach as using the intrinsic .NET functionality is a much better way forward than trying to recreate the past but sometimes people mistake these functionality as part of the the language itself. Take a look in the language specification and you will find many of thee functions that you may consider part of the language not even mentioned. The message is really - "new platform, new code, write using supported .NET functionality."
A compiler switch to do such things would be limited use as the co-evolution strategy of the compilers team means that many of the differences are simply disappearing, sure VB has XML Literals, C# has iterators and some pointer functionality but Iterators will be in next version (check out the Async CTP and Async is implemented in both languages). So I think the strategy is to remove the differences and they are diminishing. There are many other small differences but the cost/benefit probably would not justify the effort.
I'm curious. Why would one want to limit one's usage of either language to the common subset of the two? Are there any particular VB-specific language features you have in mind other than the runtime members/My namespace. It would seem a shame for either language to have productivity features handicapped arbitrarily. Imagine where the state of the .NET platform would be if no one ever used XML literals, the Aggregate, Distinct, Skip, Skip While, Take, Take While query operators, Named and Optional Arguments, Dynamic runtime binding, iterators, iterator lambdas, pointers, clean COM interop, and various other nuggets that have existed before in the past in one language or another. I can imagine some reasons for doing this but I'm curious about yours in particular, if you don't mind sharing.
I would like to flag usage of VB only .net Framework api calls. Normal legal VB syntax is not included in the flag.
I have the impression that a last wave of vb6 programmers is finally rolling in, klinging on to the flotsam that once belonged to a great ship. Let's feed them, give them dry clothing and welcome them in the woolly world of VB.Net, so we can all move on with our lives and leave vb6 for what it was.
Good info. A few people have commented on using the framework functions instead of those "old school" vb6 functions.
But there are differences, and in some ways, very convenient differences. For instance, the MID, LEFT and RIGHT functions take a string as an argument, whereas the equivalent functions on the string object +require+ that the variable actually contain a string object. If it's uninitialized, those functions will fail, whereas the older functions will still work (they just assume the value of the string is a null).
Generally, I agree, using the newer framework is the better tack. but it's good to realize there are differences that might be worth carrying forward.