September 2019
Volume 34 Number 9
[First Word]
Visual Basic on .NET Core
By Kathleen Dollard | September 2019
I started writing Visual Basic code more than two decades ago, and I understand why so many people still program in Visual Basic .NET. It has almost all of the features of C#, plus unique functionality that makes it easier for you to focus on what your software accomplishes. This comes from features in the language itself, as well as from language extensions and language stability. Visual Basic also includes unique productivity features like XML literals and in-place event hookup.
Now Visual Basic .NET 16.0 is bringing your favorite Visual Basic features to .NET Core 3.0. The essential parts of the Visual Basic .NET programming language have been on .NET Core since its early development, but developers can expect an enriched experience when Microsoft ships Visual Studio 16.3 and .NET Core 3.0 with Visual Basic 16.0 and C# 8.0 on board.
In my role working on the transition to .NET Core, I was able to dive into the technology behind the language extensions: the special functions, application models and My subsystem. These features are contained in microsoft.visualbasic.dll, also called the Visual Basic Runtime, and many are now included in .NET Core 3.0, except those dependent on Windows Forms (WinForms).
Windows Forms
Visual Basic .NET has a special relationship with WinForms, which was modeled largely on earlier versions of Visual Basic. Among all the options .NET programmers have to build applications, WinForms remains the best at getting the job done fast. In addition to traditional roles, WinForms offers a rapid way to develop thin front ends for services on-premises or in the cloud, either for production or for functional prototypes.
While the WinForms library will be available, the WinForms designers will not be part of Visual Studio 16.3. This limits the experience, so the Visual Basic .NET team decided to focus on the non-WinForms portion of the language extensions for Visual Basic 16.0. This means you can use WinForms on .NET Core with Visual Basic, but you won’t have the project property dialog to enable the Visual Basic Application Model. You’ll need either a Sub Main or a startup form, and you’ll find that the My features aren’t yet available.
Parts of the Visual Basic Runtime depend on WinForms, even for unexpected types like My.Computer. We’re splitting the runtime into the parts that are dependent on WinForms and those that aren’t, with the WinForms-dependent part to appear in a future release of Visual Basic.
Beyond these limitations, Visual Basic .NET 16.0 brings much of the functions of the Visual Basic runtime to .NET Core. This includes key features, like Fix and Mid, that you expect. Telemetry from API Port helped the team prioritize the work here, and some features with very low usage weren’t ported.
Openness and Stability
Visual Basic .NET 16.0 includes the financial and file functions that were ported by folks in the community. Of course, Visual Basic .NET has been open source since 2015. There are significant areas where you can contribute, and many of them aren’t nearly as intimidating as the Roslyn compiler! You can also be part of the revival of Visual Basic .NET communities on Facebook and Gitter. Find more about the community and language design at the Visual Basic .NET language design site (github.com/dotnet/vblang).
For this latest version of Visual Basic, the runtime was ported directly. There were no changes and no effort to “clean up” features. Things should work the same in .NET Core as they did in .NET Framework. All this is part of the deep commitment to stability within the Visual Basic team. This stability is important for backward compatibility, of course, but the commitment extends to ensuring that code written at different points in the evolution of Visual Basic continues to be easy to read. New features are incorporated slowly in Visual Basic .NET, and only those that feel natural in Visual Basic are added.
You can develop applications targeting either .NET Core or .NET Framework (.NET 4.8 and below) with Visual Studio. While .NET Framework will remain supported for a long time, developing applications on .NET Core brings a raft of advantages, including side-by-side and self-contained deployment that eliminates issues that occur when another application’s installation makes changes to production machines. For WinForms, there are new features like better high DPI support. And going forward, new capabilities in .NET, Visual Basic .NET and C# will only be available on .NET Core. In Visual Basic, you’ll get the advantages of Visual Basic 16.0 just by targeting .NET Core 3.0 (netcoreapp2.2).
Cross-Platform Support
Visual Basic .NET on .NET Core is cross-platform, although WinForms, Windows Presentation Foundation and other Windows-specific features will work only on Windows. You can find the OSes that are supported at aka.ms/net-core-3-0-supported-os. If you run a Visual Basic .NET application on an OS like Linux, features that work cross-platform will just work. If you call Visual Basic Runtime functionality that doesn’t work on that platform, you’ll get a System.PlatformNotSupportedException with a message similar to “<method> not supported on this platform.” This is the same behavior as the rest of .NET, so if you’re working cross-platform, you’ll want to test your application across the OSes where you expect to deploy, regardless of the language you use.
Some project types aren’t supported on .NET Core 3.0. For example, WebForms won’t be supported in any language. Visual Basic isn’t supported by ASP.NET Core Razor, so you can’t simply port MVC applications. And while Microsoft doesn’t offer a Web development model that’s 100 percent Visual Basic, you can use Visual Basic in ASP.NET WebAPI with JavaScript front ends, or create combined apps with views in C# Razor projects.
API Portability Anaylzer
You can test the compatibility of your applications by running the API Portability Analyzer. The tool is available for download as a Visual Studio extension from the Visual Studio gallery or as a command-line tool. Find out more at aka.ms/api-portability. The API Portability Analyzer outputs a spreadsheet listing the percent of your application that will just work in the platforms you select, in this case .NET Core 3.0. Other tabs drill into the specific APIs used in the application, as well as those that aren’t supported.
We Want To Hear from You!
The team wants to understand the issues that face Visual Basic .NET programmers moving to .NET Core and we invite your help on the next stage of that journey. If you run the Portability Analyzer and find you need things missing in the VisualBasic namespace or other Visual Basic-specific issues, let us know by opening an issue, or by commenting on an existing one, at the Visual Basic .NET language design site (github.com/dotnet/vblang).
The work we’re doing with .NET Core sets up Visual Basic for the future. Combined with Microsoft’s long-term commitment to .NET Framework 4.8, you have flexibility for both new and legacy applications in Visual Basic, one of the most productive programming languages ever created.
Changes to Visual Studio and .NET Core Installers
If you run `dotnet --info` at a command prompt, you’ll see a list of installed .NET Core SDKs and runtimes. There may be a lot more than you anticipated!
Earlier Visual Studio and .NET Core installers haven’t been removing older SDKs and runtimes when they update or uninstall. While you may need these to support SDK pinning via global.json or to target older runtimes, they might just be sitting unused on your machine.
Now, starting with Visual Studio 2019 16.3, Visual Studio will manage the versions of .NET Core SDKs and runtimes it installs. It will only keep one copy of the .NET Core SDK on each machine per channel (preview or release), and will install the latest runtime. You can target earlier runtimes by selecting them—along with their templates and targeting packs—in the Individual Components tab of the Visual Studio Installer.
When you download and install the .NET Core 3.0 SDK from dotnet.microsoft.com/download, earlier patches in the same feature band will now be removed. For example, 3.0.100 will be uninstalled when you install 3.0.102. Previews in that band will also be removed.
Each version of the SDK can target all earlier versions of the runtime, so you generally only need one. If you need additional SDKs or runtimes, you can download them from dotnet.microsoft.com/download.
You can manually remove .NET Core SDKs and runtimes, or you can clean them up using the recently released .NET Core Uninstall Tool on Windows and macOS (aka.ms/remove-sdk-runtime). Just be careful, SDKs aren’t tracked by Visual Studio, so removing the wrong ones can cause issues. If you delete something that Visual Studio needs, run “Repair” in the Visual Studio installer.
Kathleen Dollard is a principal program manager on the .NET Core team at Microsoft. She is the Program Manager for Visual Basic, contributes to the Managed Languages and works on the .NET Core CLI and SDK.