Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port remainder of Microsoft.VisualBasic #31181

Open
danmosemsft opened this issue Jul 19, 2018 · 228 comments

Comments

@danmosemsft
Copy link
Member

@danmosemsft danmosemsft commented Jul 19, 2018

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 (*)

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

@danmosemsft

This comment has been minimized.

@danmosemsft

This comment has been minimized.

Copy link
Member Author

@danmosemsft danmosemsft commented Jul 19, 2018

@govert

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

@ghost ghost commented Jul 19, 2018

@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

This comment has been minimized.

Copy link
Collaborator

@hughbe hughbe commented Jul 19, 2018

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

@danmosemsft

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

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

@ghost

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

@ghost ghost commented Jul 19, 2018

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

@KathleenDollard

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

@bbowyersmyth bbowyersmyth commented Jul 21, 2018

I'll grab Microsoft.VisualBasic.Collection

@reduckted

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

@danmosemsft

This comment has been minimized.

Copy link
Member Author

@danmosemsft danmosemsft commented Jul 22, 2018

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

@danmosemsft

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

@paul1956 paul1956 commented Jul 5, 2019

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

<Global.System.Diagnostics.DebuggerStepThroughAttribute()>  _
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

This comment has been minimized.

Copy link

@Berrysoft Berrysoft commented Jul 5, 2019

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

@KathleenDollard

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

@KathleenDollard KathleenDollard commented Jul 7, 2019

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

@KathleenDollard

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

@mmusin mmusin commented Jul 9, 2019

@danmosemsft @KathleenDollard Are there plans to add .net standard target to the library?

danmosemsft added a commit that referenced this issue Jul 10, 2019
* Port of the VB Financial module (#31181)

* Added more tests for the Financial module

* Skip some tests on alpine
@KathleenDollard

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

@KathleenDollard KathleenDollard commented Jul 21, 2019

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

@paul1956

This comment has been minimized.

Copy link
Contributor

@paul1956 paul1956 commented Jul 21, 2019

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

This comment has been minimized.

Copy link
Contributor

@ehasis ehasis commented Jul 22, 2019

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

@KathleenDollard

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

@paul1956 paul1956 commented Jul 23, 2019

In order to use System.Windows.Forms.Dll I need to change both ref and src Microsoft.VisualBasic.Core project files from <Project Sdk="Microsoft.NET.Sdk"> to <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> and add <UseWindowsForms>true</UseWindowsForms>
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

This comment has been minimized.

Copy link
Member Author

@danmosemsft danmosemsft commented Jul 23, 2019

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

@flieks flieks commented Aug 17, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.