Disclaimer: Let me be clear in that I am ***not recommending*** doing what I'm about to discuss except for the specific scenarios where it is ***needed***. With that said...
When working with platforms that do not have full support for the Visual Basic .NET runtime; it can sometimes be difficult to get things working and you may even decide to purchase a tool to convert the project to C# and ditch VB. (Again, ***not recommended***.)
One way to get around this is to build your project in such a way that you are pretty much guaranteed that the code will execute regardless of the target platform. This can be done, using VB (or C#), with relative ease in VS 2012 (and VS2010 SP1 with a free add-in) by leveraging Portable Class Libraries and choosing to target every platform on the list. This will provide you an environment that comes pretty close to enforcing that you only use features and functionality that is available across all of the selected platforms.
With regards to Portable Class Libraries and Microsoft specific platforms, this is a great solution. However, if you want to target non-Microsoft related platforms (Android, iOS, Linux, etc.), these platforms may not have the same level of support. However, all is not lost. Microsoft, with the release of Visual Studio 2010 SP1, has accepted this to be the reality and provide for functionality to support these scenarios.
There are three different features available to support these scenarios:
1. Completely remove the Visual Basic runtime; forcing that you use only the functionality made available as part of the Framework. (/vbruntime-)
2. The ability to reference a replacement version of the Visual Basic runtime; one from a third party or even one that you create in order to cover the functionality that you would typically utilize when the runtime is normally available. (/vbruntime path)
3. Include the most basic functionality available through the Visual Basic runtime by embedding it within the assembly; thus removing the external reference. (/vbruntime*)
Of these options, I believe that the 3rd option provides the best of both worlds. All of the essential conversion functions, attributes, additional support for Try/Catch When, For Each, string comparison, Chr, Asc and a few "useful" (aka common) constants are included.
This functionality is exposed through the command line compilers switches. There is nothing in the Visual Studio IDE that provides access to this switch.
This is all fine except for one significant problem. For any project of significant size, compiling your project from the command line to utilize these switches can be a very daunting task. To complicate matters further, there is no way to specify this switch on the msbuild command line. If only there was a way that this could be done.
As it turns out, there is, in fact, no switch on the msbuild command line to handle this; however, you can modify the .proj file to include this support. To do so, from within Visual Studio:
1. Load your solution.
2. Right click on the project in the Solution Explorer.
3. Select the Unload Project menu item.
4. Right click on the unloaded project and choose the Edit menu item.
5. In the editor, find the first <PropertyGroup> section.
6. Create a new line to this section and enter <VBRuntime>Embed</VBRuntime>.
7. Save the file.
8. Right click on the unloaded project and choose the Reload menu item.
At this point, you may see a ton of errors related to functionality that is now missing. It appears that the IDE is also able to handle this flag; making it a bonus. (Disclaimer: I'm not sure as to how well it does this.)
Now when you build your project, it will no longer include an external reference to the VB Runtime. This, of course, means that you will not be able to leverage many of the features that it provides; however, it does provide a means to use VB to target more platforms.