Cross Platform Visual Basic

_I don't think that means what you think it means_

(Sorry for the Princess Bride reference and in this case) What is Visual Basic? What I think it means and what you think it means probably differ, because I think it means different things depending on context. You probably think it means "the thing I need to get my job done".

Visual Basic compiler - runs on core. .NET Core SDK - supports Visual Basic. The _language as defined by the compiler_ works the same.

But what about the Visual Basic runtime. Many of the "function like" features of VB are in the runtime and there is a subset that was defined in the Windows Phone days that has the extremely unfortunate name of "VB Core". This subset has been cross platform on .NET Core since 1.0 (at least I think, I didn't test, it's certainly been there since 2.0).

In .NET Core 3.0 and .NET (Core) 5.0, more of the Visual Basic runtime moved. We can't move it all because some of it relies on features that are no longer available. The most painful example will be single instance applications, which relied on Remoting. There will be other things missing. I think this is in the next preview. (For single instance, there is an issue in the WinForms repo because if we reimplement this feature, it would be nice for everyone to be able to use it.)

I want to shout out and thank @Paul1956 for his help with the port.

The port of the Visual Basic runtime had a single goal: Move as much of the VB Runtime as possible to minimize the pain of porting your Visual Basic apps. You can guess that an app written under duress at the start of the century doesn't meet today's standards for separation of concerns. There are quite unexpected parts that depend on Windows and/or WinForms and that @##%#% MsgBox. We solved this by putting significant parts of the VB Runtime into a second assembly that resides in the WinForms repo. This part of the runtime depends on Windows. There is type forwarding which means you do not need to worry about this if you are on Windows and significantly, if we find ways to move more back into the cross platform part of the VB Runtime, we should not break anyone (don't just depend on the WinForms part, then we may break you, but who would do that?).

There are key things that aren't on .NET Core: WCF server and WebForms come to mind. If you're using these technologies, it's not really a port, but a rewrite into other technologies. For WCF, this is one of the reasons our continuing support of .NET Framework is important - leave those servers on Framework as long as you want.

If you aren't using these workloads, it will not be a recompile: it will be a port. After you port, you should still be able to target .NET Framework or .NET Standard. I'm working to get Visual Basic bits into the API Portability Analyzer, but we don't usually do it this early in the preview cycle. You can just recompile when we have a preview with the bits if you want to take that route to seeing what you need to change (if you do that, note that there are filters in the error dialog window to specific parts of you app and at the top of columns to filter out specific errors).

If you have not customized your project file, the porting tool for the project file may work for you, otherwise that part will be painful. [There is a porting guide in docs](https://docs.microsoft.com/en-us/dotnet/core/porting/).

Maybe you want to try Visual Basic on .NET Core without the Visual Basic Runtime, that works today in .NET Core - no previews required and you don't have to wait for .NET 5.0. Just go try it and let me know how it goes!!! (If you use the Visual Basic runtime in .NET Core 3.0 you get the subset defined in the VB spec).

Then there are the .NET Core things. We made changes in how we think about the Framework. The two I think will be most surprising for VB developers are linked: .NET Core is not delivered as part of Windows and the [support policy is about 3 years](https://dotnet.microsoft.com/platform/support/policy/dotnet-core). Also, the compiler does not protect you against making calls not supported on a platform. You will get "platform not supported" exceptions.

Is this a bit confusing? Yes. Because I think of all the ways people might approach the framework and focus a bit on the high percentage that are WinForms developers who I suspect amazing things using Visual Basic in Visual Basic ways. Will this be confusing to you in the end? No. You will figure out "OK, I care about that, and I don't care about this other thing."

If you play with .NET Core, please let me know how it goes.