Microsoft.VisualBasic.dll on top of netstandard

[iainnicol]

Split off from https://github.com/dotnet/corefx/issues/14300

The usual Microsoft.VisualBasic DLL exists in .NET Core, but only with a tiny API subset. The API in .NET Core shouldn't be extended. However, I would be interested in a fuller subset of the the DLL which could sit on top of netstandard.

As @AnthonyDGreen writes, we would have to consider

whether [it] should exist and what should be in it and how we deal with what's left out moving forward.

For a start, I presume it would be much easier to leave out the My* namespaces, and also PInvoke heavy code.

[gafter]

This doesn't sound like a VB language issue. Perhaps it belongs in the Roslyn repo?

[AnthonyDGreen]

Hey @gafter,

I asked him to create it here for the time being.

It's not going to perfectly fit in either repo but given how the VB runtime interacts with the language I'm comfortable having it here. Whether and how the My namespace works when targeting netstandard, for example, is as much a language decision as it is a library one. Not to mention late-binding (except now I just mentioned it).

[AdamSpeight2008]

I think we should not port the legacy functionality across. It's time to leave the "old fashioned" VB6 approach behind, and use the .net approach. Especially on dot net core.

[rolfbjarne]

For pure managed (doesn't require P/Invokes, or any other API that is platform-specific) API I don't see a reason not to make them available in .NET Core (assuming the required underlying API is available in .NET Core).

IMHO the origin of the API doesn't matter, only its usefulness does.

[Bill-McC]

Is there a list of what is in, what's not ?

[KathleenDollard]

Is this issue addressed with the expanded surface area of .NET Standard 2.0?

[iainnicol]

Thanks for asking. No, the surface area for Microsoft.VisualBasic was not extended (or at least not significantly).

[iainnicol]

I'm going to close this, given the news in issue #280 that the corefx team want the VisualBasic dll ported to .NET Core 3.

My understanding is that Anthony D Green originally envisaged .NET Core could give VB the possibility of having having a newly designed VisualBasic dll. This new dll would possibly be slimmed down, and certainly be more modern (e.g. async support), compared to the old desktop version of the VisualBasic dll.

Regarding being slimmed down, .NET Core has since decided to instead massively expand the API surface. I think that's good for compatibility. A .NET linker now exists, which can be used where slimness matters.

Regarding modern API support (e.g. async), I think that's something that could be feasibly designed and added in a separate NuGet package, community maintained. But that should probably be done after the port of the existing VisualBasic dll to .NET Core.

[KathleenDollard]

Thanks @iainnicol

I agree with your assessment here. A core tenet of .NET Core 3 is code compatibility (not so with earlier .NET Core versions), so this is a good time to move the VB runtime, then consider changes.