Cross Platform Visual Basic

[KathleenDollard]

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.

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

[tverweij]

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

If it does not work will it be fixed?

[KathleenDollard]

We will fix bugs, for sure.

[tverweij]

Where can we post them when we find them? On this forum or somewhere else?

[ericmutta]

@KathleenDollard: The port of the Visual Basic runtime ...

Is this porting work happening in the open here on GitHub or is it internal?

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

Personally, I no longer think of the .NET Framework or of .NET Core. I write most code for .NET Standard 2.0 and try not to think much about the frameworks unless I have to (e.g. for UI).

I am currently learning ASP.NET and the docs keep recommending I try ASP.NET Core which would have been one reason for me to take a serious look at .NET Core. However, there are no templates for VB on ASP.NET Core so that exercise ended right there and I went back to the ,NET Framework 4.x where at least ASP.NET supports VB.

As it stands today, the way I do "Cross Platform VB" is to target the .NET Standard 2.0. I have over 30,000 lines of VB code that runs on Android, Windows and Linux/Ubuntu...and I didn't touch .NET Core to do it! :man_shrugging:

[VBAndCs]

@ericmutta

there are no templates for VB on ASP.NET Core so that exercise ended right there

Create an ASP.NET app in C#, then convert all code to VB, including changing every .cs in file names to .vb, and all will work just fine! You will only need .cshtml files because VB.NET razor syntax is not supported. .cshtml files will work fine but you will not get editor support for the c# code within, which is always a simple code. But if you need support, design them in a C# project then copy them to the VB one. But note that the code behind file in the VB project will be a VB file with the extension .cshtml.vb This is a VB template I created for ASP.NET Core 3 while it was in preview. You can copy and modify the generated files as you want, and erase all vbxml code: https://github.com/VBAndCs/Vazor/blob/master/VazorTemplateSetup.zip?raw=true

[VBAndCs]

@KathleenDollard Regardless of the fancy title, VB.NET can't really do anything out windows. Just class libraries that is compiled to byte code to work in C# apps. I am convinced that the decision to get rid of VB was taken at 2017. For one reason, the webassembly support for C# could work out of the box for VB.NET if just it was written as IL to Webasm compiler! I see no real benefit to use VB.NET in .Net Core in its current state. I think it will be better if we ship .net framework apps in docker containers to run on other platforms!

[WolvenRA]

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

@KathleenDollard I read through this post a couple of times... and I'm still not clear on what you're trying to say. Or maybe I'm looking for information that you're not trying to provide. I read Anthony Green's blog post (3/15/2020) which I found quite helpful and even hopeful. For me, the most important take away from his post was the following:

"... as conversations take place about where we are, everyone understands that the current situation is entirely and easily avoidable. The F# community, a much smaller community than that of VB.NET has (and has always had) a dedicated team working and advocating on their behalf throughout the .NET ecosystem as their main job—their first priority—every day. There is no reason that after 18 years of loyalty, the VB.NET community doesn’t deserve at least that much. Focus your intentions on this goal because regardless of what anyone says the support of a small 3-5 person, agile, empowered, autonomous, passionate, and dedicated VB.NET Team, separate from C#, is the only support that means anything."

So my question is, what can we as a community do to recreate the separate (from C#), agile, empowered, autonomous, passionate, and dedicated, VB.Net focused team at MS that Anthony describes? I know this is exactly what I'm looking for and I suspect it's what 99% of the rest of the VB.Net developers and software companies are looking for.

I don't believe there's any valid reason VB can't continue to be kept "current" with C# just as it has for the last 18 years... i.e. whatever you can program in C# you can program in VB. That's what VB.Net means to me.

[salelele]

What we are working with more than half of the time is ASP.Net Web forms, a little bit of ASP.Net MVC and Windows forms. But it will not hurt to install and try out what is available now in .Net core.

[KathleenDollard]

@ericmutta This is why I wrote this post. It is a bit confusing what works and what doesn't, but the language (without the runtime) has always worked.

@VBAndCs You have been able to do WebAPI all along. There aren't templates because the ASP.NET template engine is "interesting". Separately we are working on that. This is why we're moving WinForms.

We haven't been saying "of course VB is cross platform" because we don't think VB is just a language. But that's also led to an implication that nothing works, which of course is not true either.

[DualBrain]

I was going to write a long reply... decided against it. I'll just make it clear that I'm very interested and ACTIVE with regards to VB being cross-platform. ;-) I'm also a HUGE fan of .NET Core and plan on writing application on top of this platform for many, many, many years to come... in VB. :-D

[DualBrain]

Just a quick note for those that may be interested... please check out https://github.com/DualBrain/Community.VisualBasic regarding the subject of a cross-platform VB runtime.