Question: Microsoft.VisualBasic functions port

[bbowyersmyth]

I have some ex-VB assemblies that still call into some of the old legacy VB helper functions. Do you mind if I port some of that surface area to core?

Specifically:
Strings.Right
Strings.Left
Strings.Mid
Strings.Replace
DateAndTime.DateDiff
Information.IsDate
Information.IsNumeric

[stephentoub]

@weshaggard, @danmosemsft, was there any discussion about including Microsoft.VisualBasic in netstandard? Regardless, any reason we wouldn't want the full set of APIs from it available in core?

[weshaggard]

There was a discussion about it being part of netstandard and we decided to keep it on top of netstandard for now. However that doesn't mean we shouldn't include more APIs in core for it. We have to be a little careful as there are a lot of the "My" APIs in VB that require dependencies that aren't in core, but if the dependencies are present then I don't know of any reason we shouldn't include them.

[bbowyersmyth]

Agreed, it should not be part of netstandard.

I realise that this is not going to be a priority for many people so I'm happy to do the port. The reference source is not available so I would need to be sent that. Alternatively, with your approval, I can work from the MSIL. Either way is fine by me.

We can start with the top level namespace and go from there if there's any interest.

[danmoseley]

@VSadov, @OmarTawfik you own this namespace. What are your thoughts about porting these?

[iainnicol]

I would volunteer to assist @bbowyersmyth in porting some of the Microsoft.VisualBasic assembly, to work on top of netstandard.

However, I would prefer to work from MIT Reference Source (à la #17386) and not MSIL.

Politely pinging @VSadov, @OmarTawfik.

[AnthonyDGreen]

@iainnicol Thanks for volunteering. Ever since 2010 our default approach to new platforms has been "VB Core", a compilation mode that embeds the essential runtime bits required by the VB language. The surface area of VB Core was selected to be minimal so as to ensure maximum portability.

We certainly wouldn't want to add more functions to VB Core. But you raise a good question about a netstandard Microsoft.VisualBasic dll and whether one should exist and what should be in it and how we deal with what's left out moving forward. That'll take some serious design work. Could you file an issue over at https://github.com/dotnet/vblang to track this?

@bbowyersmyth, could you elaborate a bit more on what functionality in those functions that you're dependent on? If, as you said, these are ex-VB assemblies perhaps now is the time to move to .NET string functions?

[AdamSpeight2008]

Personally I would want use to port over the legacy functionality to .net core. Let .net core be a "pure" .net implementation.

[bbowyersmyth]

@AnthonyDGreen I'm dependent on them now purely because they were already being used. I can certainly move them over to be using BCL functions. It just requires some effort as they are not one-for-one replacements. For example Left can take a length longer than the string and it will just return the string instead of giving an error like Substring will.
I'm ok if the call is to leave them in the past.

[danmoseley]

This is tracked in https://github.com/dotnet/corefx/issues/31181

[bimonsubio1984]

Hello,

You can find a ported version here:
https://ufile.io/nyzye

Some Windows specific stuff is missing.

[bimonsubio1984]

https://github.com/bimonsubio1984/CommonCore/tree/master/Ported.VisualBasic