Port remainder of Microsoft.VisualBasic

[danmoseley]

This tracks porting to .NET Core the rest of the types in Microsoft.VisualBasic, now that we've published the original sources.

Contributions are welcome! The porting process is essentially

1. Pick some types.
2. Get the original .NET Framework code from referencesource
3. Add it to the src project, make it compile. Fix style to match style guidelines, update license headers to match existing code.
4. Add the API to the ref. Here's an example of a complete ref generated from the .NET Framework binary.
5. Write tests, add to the tests project, and make them pass.
6. Put up a PR then we can check the type off.

Here is an example change that ported some more of Strings.

To track progress, here is a list of classes/structs that aren't in .NET Core (or are present, but missing some members). I am not listing the members nor any enums: that detail is here: https://gist.github.com/danmosemsft/d34ec1055c4c23aefcd047089538d3a1

namespace Microsoft.VisualBasic

• Collection
• ComClassAttribute
• Constants
• ControlChars
• Conversion
• DateAndTime
• ErrObject
• FileSystem
• Financial
• Globals
• HideModuleNameAttribute
• Information
• Interaction (*)
• MyGroupCollectionAttribute
• SpcInfo
• Strings
• TabInfo
• VBFixedArrayAttribute
• VBFixedStringAttribute
• VBMath

namespace Microsoft.VisualBasic.ApplicationServices

• ApplicationBase
• AssemblyInfo
• BuiltInRoleConverter
• CantStartSingleInstanceException
• ConsoleApplicationBase
• NoStartupFormException
• StartupEventArgs
• StartupNextInstanceEventArgs
• UnhandledExceptionEventArgs
• User
• WebUser
• WindowsFormsApplicationBase (*) (see Support WindowsFormsApplicationBase.IsSingleInstance winforms#2056)

namespace Microsoft.VisualBasic.CompilerServices

• BooleanType
• ByteType
• CharArrayType
• CharType
• Conversions
• DateType
• DecimalType
• DesignerGeneratedAttribute
• DoubleType
• ExceptionUtils
• FlowControl
• HostServices
• IncompleteInitialization
• IntegerType
• InternalErrorException
• LateBinding
• LikeOperator
• LongType
• NewLateBinding
• ObjectFlowControl
• ForLoopControl
• ObjectType
• Operators
• OptionCompareAttribute
• OptionTextAttribute
• ProjectData
• ShortType
• SingleType
• StandardModuleAttribute
• StaticLocalInitFlag
• StringType
• Utils
• Versioned

namespace Microsoft.VisualBasic.Devices

• Audio (*)
• Clock
• Computer
• ComputerInfo
• Keyboard (*)
• Mouse (*)
• Network (* - progress dialog)
• NetworkAvailableEventArgs
• Ports
• ServerComputer

namespace Microsoft.VisualBasic.FileIO

• FileSystem
• MalformedLineException
• SpecialDirectories
• TextFieldParser

namespace Microsoft.VisualBasic.Logging

• AspLog
• FileLogTraceListener (*)
• Log

namespace Microsoft.VisualBasic.MyServices

• ClipboardProxy (*)
• FileSystemProxy
• RegistryProxy
• SpecialDirectoriesProxy

namespace Microsoft.VisualBasic.MyServices.Internal

• ContextValue

A few types may not be portable yet because of dependency issues - either they depend on something that isn't quite yet in .NET Core (principally Windows Forms) or that is, but is in a higher dependency level (Windows Forms again). I have marked some of these with (*). This problem can be solved but I suggest that we skip these for the moment.

ccing folks who have expressed interest in the past: this is now unblocked.
@KathleenDollard @OmarTawfik @karelz @jaredpar
@amshekar @bbowyersmyth @iainnicol @EdwinEngelen @kaiukdevelopment @ocdtrekkie @ericmutter @MohammadHamdyGhanem

[danmoseley]

@craigajohnson @RealDotNetDave @VBDotNetCoder @Nukepayload2 @AnthonyDGreen

[danmoseley]

@franzalex @beppe9000 @govert

[govert]

@danmosemsft Thanks - that's going to be helpful.

I clicked on the Collection source...
What might Telesto be? https://github.com/Microsoft/referencesource/search?q=TELESTO&unscoped_q=TELESTO

I'm presuming it's some limited platform, and we'd be in the NOT TELESTO world for .NET Core?

[danmoseley]

I think TELESTO was used to limit the size for Silverlight and we want to keep the extra size,

@danmosemsft
I suggest that classes used with My object should be added to corefx to be available to all languages even if you move them to other namespaces (out of visualbasic namespace), as they have more functionality not offered by corefx.
Adding clsses especially to one language doesn't make sense and is not efficient. Languages can only differ in syntax. These classes will still be accessed via My in vb.net but used directly as regular classes fromany language. Application framework also should be available in c#. I import it from vb just to make c# app a single instance.

[hughbe]

Can I grab ComClassAttribute, HideModuleNameAttribute, MyGroupCollectionAttribute, VBFixedArrayAttribute, VBFixedStringAttribute, DesignerGeneratedAttribute, OptionCompareAttribute, OptionTextAttribute and StandardModuleAttribute?

[danmoseley]

@MohammadHamdyGhanem could C# not access My like any other type? But otherwise, we have no plans to make My more widely available to C#. It was specifically designed for the coding style of VB developers. Languages do not differ only in syntax. They have different developer groups as do their accompanying libraries.

[stephentoub]

could C# not access My like any other type?

@danmosemsft, no, it's a figment of the VB compiler's imagination; it emits the "My" support into the binary at compile-time.

@danmosemsft
I didn't ask to add My to C#. In fact My has some long expressions that I don't like in VB.
I'm asking to relocate the classes use by My, from Microsofr.VisulBasic Namespace to the CoreFx namespaces suitable for thier functionality (i.e tracing classes go to the namespaces where other tracing classes are), so they can be used normally from any .NET lang.uage as any othe classes, whithout adding a reference to Microsofr.VisulBasic Namespace first (C# programmers hate this as hell).

[weshaggard]

@danmosemsft as we port these to corefx we need to be very careful it doesn't require us to put everything into the shared framework. Microsoft.VisualBasic.dll was one of the assemblies in .NET Framework that had static dependencies to almost everything.

[KathleenDollard]

@MohammadHamdyGhanem Can you list some of the classes you want to see in a non-VB namespace? That would go through CoreFx, probably with the involvement of CSharpLang.

@KathleenDollard
FileSystem
Financial
ApplicationBase
CantStartSingleInstanceException
StartupEventArgs
StartupNextInstanceEventArgs
UnhandledExceptionEventArgs
WindowsFormsApplicationBase ()
TextFieldParser
AspLog
FileLogTraceListener ()
Log
ClipboardProxy (*)
FileSystemProxy
RegistryProxy
SpecialDirectoriesProxy

[KathleenDollard]

That is pretty broad.

I wanted to determine if there were a few things that could be justified to the CoreFx with user stories, etc. This indicates you want the VB experience.

Since the goal is support for moving existing apps, these features need to stay in the VisualBasic namespace to avoid breaking people.

[bbowyersmyth]

I'll grab Microsoft.VisualBasic.Collection

[reduckted]

I know there's the backward-compatibility argument, but has there been any discussion around deprecating/not porting some of these classes? Take, for example, Collection. Why would anyone use that over say, List(Of T), or Dictionary(Of TKey, TValue)? It's not even a generic collection.

And then there's the ErrObject 😨 Does anyone still use that over Try/Catch blocks?

Information.IsArray(), Information.IsError() and Information.IsNothing(). What's the point of them?

And some of these aren't VB-specific as @MohammadHamdyGhanem points out. FileSystem.DeleteDirectory is a great example. It lets you move directories to the recycle bin. Surely that's something that a C# programmer would want to do.