# Port remainder of Microsoft.VisualBasic #31181

Open
opened this issue Jul 19, 2018 · 228 comments
Labels
Milestone

### danmosemsft commented Jul 19, 2018 • edited by cston

 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 Pick some types. Get the original .NET Framework code from referencesource Add it to the src project, make it compile. Fix style to match style guidelines, update license headers to match existing code. Add the API to the ref. Here's an example of a complete ref generated from the .NET Framework binary. Write tests, add to the tests project, and make them pass. 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 (*) 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
This was referenced Jul 19, 2018

### govert commented Jul 19, 2018

 @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?

### danmosemsft commented Jul 19, 2018

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

### ghost commented Jul 19, 2018 • edited by ghost

 @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 commented Jul 19, 2018

 Can I grab ComClassAttribute, HideModuleNameAttribute, MyGroupCollectionAttribute, VBFixedArrayAttribute, VBFixedStringAttribute, DesignerGeneratedAttribute, OptionCompareAttribute, OptionTextAttribute and StandardModuleAttribute?
added this to the Future milestone Jul 19, 2018
mentioned this issue Jul 19, 2018
mentioned this issue Jul 19, 2018

### danmosemsft commented Jul 19, 2018

 @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 commented Jul 19, 2018

 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.
mentioned this issue Jul 19, 2018

### ghost commented Jul 19, 2018

 @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 commented Jul 19, 2018

 @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 commented Jul 19, 2018

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

### ghost commented Jul 19, 2018

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

### KathleenDollard commented Jul 20, 2018

 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 commented Jul 21, 2018

 I'll grab Microsoft.VisualBasic.Collection
mentioned this issue Jul 21, 2018

### reduckted commented Jul 22, 2018

 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.

### paul1956 commented Jul 22, 2018

 @reduckted When I ported a VB App to Portable, lack of the complete FileSystem class caused issues, but the portable class and I assume .NetCore have the similar if not identical functionality but different API's. People using .NetCore don't need another way to do the same thing but VB needs a (thin) layer to keep doing what we were doing without changing lots of code. Hopefully it gets written once and everyone gets to use it. I have never looked at VB Collections but I assume the implementation would be a thin layer over the functions you list. Years ago I ported a library of VB6 string functions to use with VB.net over time I have stopped using them because it just confused people but it allowed a quicker port.

### paul1956 commented Jul 22, 2018

 @danmosemsft I tried to clone the src project using Open in Visual Studio and I get the dialog below. I have the extension and have no issue Cloning other projects like DotNet/Roslyn.

### danmosemsft commented Jul 22, 2018 • edited

 @paul1956 hmm in not sure what to suggest. If you pick some other random repo now, does it work?

### danmosemsft commented Jul 22, 2018

 @reduckted has there been any discussion around deprecating/not porting some of these classes There are many customers who have existing apps that use one or more existing libraries that happen to have been written in VB. They cannot migrate to..NET Core which is why we are porting this verbatim. You're definitely right I wouldn't recommend using some of these types in new code. Those types maybe could have some text in the docs.

### paul1956 commented Jul 5, 2019 • edited

 I am seeing a number of minor issues with VB App visuals and some more major issues. Some things are off by a pixel so things look different, the SplitContainer control works differently on startup (splitter distance is ignored) and most importantly the ApplicationDesigner is missing and you can't use the one from Framework. How do you set the items below and without Me.MainForm the application require Sub Main to start and cleanup doesn't happen. Me.IsSingleInstance Me.EnableVisualStyles Me.SaveMySettingsOnExit Me.ShutDownStyle _ Protected Overrides Sub OnCreateMainForm() Me.MainForm = Global.CSharpToVBApp.Form1 End Sub There is also some odd behaviors of all Dialogs, you need to assign a "New" instance of them to a variable and then dispose of the variable. ' Framework If VS_Selector_Dialog1.ShowDialog(Me) <> DialogResult.OK Then ' Core Dim VS_Selector As New VS_Selector_Dialog1 If VS_Selector.ShowDialog(Me) <> DialogResult.OK Then  What is the best way to report each item? Are some of them known?

### Berrysoft commented Jul 5, 2019

 @paul1956 I think the second one is related to Roslyn team, because it is actually a My extension.

### KathleenDollard commented Jul 5, 2019

 @paul1956 and everyone We're assessing additional work for WinForms and need to understand the range of problems that still exist. You're help in reporting these is appreciated. We don't have a designer for WinForms yet. That is coming. We're assessing the project properties, which drove the MyApp xml and generated file and the startup/clean up events. We still have significant holes in the My story. Can you report apparent WinForms issues in the WinForms repo:. I'm sure separate issues would be appreciated. This would include the off by pixel problem and the split container. The ShowDialog problem probably remains here as part of the issues with My.

### paul1956 commented Jul 6, 2019

 @KathleenDollard it looks like the pixel issue is know and closes by #1122. I am on the fence on this one, I like the new font but it means a lot of work to fix UI issues.

### KathleenDollard commented Jul 7, 2019

 @paul1956 Got it. The link for that issues is 1122

### KathleenDollard commented Jul 7, 2019

 Since this also affects C# and the WinForms team has decided to make that change, I won't worry about it, unless you think it creates a special problem for VB

### paul1956 commented Jul 8, 2019

 @KathleenDollard As I said I actually agree with the change, but is should be highlighted otherwise others will go through what I did trying to figure out why my apps looked differently and things didn't fit and controls blocked other controls. Because VB doesn't have the designer I thought I had no way to fix the issues. For me the easy solution was to set the Fonts in my Framework version, assign everything and then the app works in both framework and core and look identical. The split container issue also went away when I changed the fonts and aligned everything.

### ehasis commented Jul 9, 2019

 Is this tracking updated? I'm trying to find something to contribute with, but looks like many of the unmarked is already implemented.

### mmusin commented Jul 9, 2019

 @danmosemsft @KathleenDollard Are there plans to add .net standard target to the library?
added a commit that referenced this issue Jul 10, 2019
 Port of the VB Financial module (#31181) (#39147) 
 b6edaf0 
* Port of the VB Financial module (#31181)

* Added more tests for the Financial module

* Skip some tests on alpine
mentioned this issue Jul 18, 2019

### KathleenDollard commented Jul 18, 2019

 @ehasis It looks like you are correct that this has gotten out of date. I'm on vacation until July 28, and I think @cston and @danmosemsft are tied up won't have time to cross check this list. If you see any that have been ported, please feel free to add a comment here, and we will update the list when we can. Sorry.

### paul1956 commented Jul 20, 2019

 @KathleenDollard I have a reasonable implementation of MsgBox with interactive tests as a NuGet package or as part of "Interaction.vb" how do you recommend it gets published? The NuGet version is not Multi-Language.

### KathleenDollard commented Jul 21, 2019

 @paul1956 Is it a direct port or a better implementation?

### paul1956 commented Jul 21, 2019 • edited

 A direct port, it is fairly trivial not sure how you would make it better and still be compatible. The only mystery is who sets IVBHost. I created the interface in Compiler Services according to the reference source, created the property VBHost as IVBHost but nothing ever calls Set and that is true of the reference source as well. Without Set being called MsgBox works and passes all the same tests as in Framework but I am sure I am missing something. I have the tests in C#, I have cloned CoreFx and created a MsgBox branch. The code itself is in Interaction.Windows and Interaction.Unix which just throws and exception for now but satisfies the Ref requirement.

### ehasis commented Jul 22, 2019

 @danmosemsft what tool did you used to generate that diff that you linked on this issue?

### KathleenDollard commented Jul 22, 2019

 @paul1956 Visual Basic.NET WinForms specific stuff will be post 3.0, @cston can look at your port then. In the meantime, it would be great if people could get it, so you authoring a NuGet package seems a good idea.

### paul1956 commented Jul 23, 2019

 I published the source and tests https://github.com/paul1956/MsgBox, I will work on in getting on NuGet when I figure out how. I realized the Microsoft.VisualBasic dll is not yet on Microsoft.NET.Sdk.WindowsDesktop

### danmosemsft commented Jul 23, 2019

 I realized the Microsoft.VisualBasic dll is not yet on Microsoft.NET.Sdk.WindowsDesktop @paul1956 can you clarify what problem you are having? M.VB.dll is referenced by default by Microsoft.NetCore.App , which is referenced by all .NET core apps.

### paul1956 commented Jul 23, 2019 • edited

 In order to use System.Windows.Forms.Dll I need to change both ref and src Microsoft.VisualBasic.Core project files from to and add true to both projects. I then get the error below Microsoft.VisualBasic.Core.cs(920,16): error CS0234: The type or namespace name 'Windows' does not exist in the namespace 'System' (are you missing an assembly reference?) [C:\Users\PaulM\Source\Repos\corefx\src\Microsoft.VisualBasic.Core\ref\Microsoft.VisualBasic.Core.csproj] This probably also breaks non-Windows builds since I don't see a way to make this change conditional on platform(I don't know enough about the project system to know how to pake the project conditional on plafform type).

### danmosemsft commented Jul 23, 2019 • edited

 Oh, I misunderstood. I thought you were talking about creating new VB projects. No, it is not possible to reference Winforms from the CoreFX repo. It is a matter of layering. If we want to use Winforms from M.VB.dll, then the work would have to happen in the dotnet/winforms repo, not in CoreFX. Technically how this would work is that in dotnet/winforms they would build M.VB.dll, and it would type-forward to M.VB.Core.dll (the thing in CoreFX) for everything already in CoreFX. There is probably not all the necessary infrastructure set up yet in order to do this. As @KathleenDollard says, that would be post 3.0 work, and it would I think be entirely in the dotnet/winforms repo. Currently the team in the dotnet/winforms repo is fully occupied by 3.0 so they likely can't help take PR's for this for a few months. We can continue to take PR's in this repo for types in M.VB.dll that do not require Winforms (or anythign else that's not in dotnet/corefx today) subject to @cston having time to review it. Thanks for the help.

### paul1956 commented Jul 23, 2019

 I assume that you would not want MsgBox in dotnet/winforms since it is part of the VB Runtime but it can't go in Microsoft.VisualBasic because it depends on dotnet/winforms hence my dilemma, I need to drop this for now. I assume the same is true of CompilerServices.VBHost.

### danmosemsft commented Jul 23, 2019

 Being in dotnet/winforms repo doesn't require it's implemented in a winforms assembly. It's just a convenient repo at the right "layer". Anyway as you say, we can figure this out when 3.0 is out.

### paul1956 commented Jul 24, 2019

 @danmosemsft I have not seen an answer to @ehasis as to what you are still looking for contributions on.

### nguerrera commented Aug 4, 2019

 The lack of ContextValue is currently causing all VB class libraries to fail to build, now that we no longer use VBRuntime=Embed in the build. See #40012

### flieks commented Aug 17, 2019 • edited

 ContextValue is probably fixed in preview9 because i got it on indexForFile = indexForFile.Replace(DecimalSeparator, "") but now i get Could not load type Microsoft.VisualBasic.ApplicationServices.ApplicationBase... on the same line of code

### KathleenDollard commented Aug 19, 2019

 @flieks Sadly, we had to pull ApplicationBase out of .NET Core 3.0. We are working to put it back as quickly as possible, but this will not be done for the .NET Core 3.0 release. Explanation: we had hoped to finesse the many intricate dependencies the Visual Basic Runtime has on WinForms and place some of this into the CoreFx part of the Runtime. This was our status prior in earlier previews. This turned out to be a bad decision on our part. The experience if WinForms was not present (odd runtime failures for certain things) was terrible. We are in the process of moving this to a WinForms version of the runtime. This will be invisible, but will require WinForms be referenced for ApplicationBase, and many other features. I know these don't have a logical dependency, but changing the internal dependencies would be a breaking change.

### paul1956 commented Aug 20, 2019

 @KathleenDollard Does this mean VB will be forever tied to Windows or only VB WinForms/WPF applications will be tied to Windows or something else? Specifically will I be able use a VB Class library outside of Windows?

### KathleenDollard commented Aug 20, 2019

 You will be able to use a Visual Basic Class Library. You can do that today. The problem is in portions of the Visual Basic Runtime that you might think should be available that are problematic. For example: ApplicationBase, but I don't expect that to affect a library. For a class library the things you would be missing would be stuff like My Computer.

### flieks commented Aug 26, 2019

 @KathleenDollard ok so maybe as workaround for String.Replace() i should add some code that does the replace (maybe with split/indexOf/substring) and hope that doesn't use another part of ApplicationBase.. And then check if i can execute the rest of the code (it's a very big VB solution with many forms and spreadsheets) So the ApplicationBase will be for .NET core 3.1 ?