Sdk: VB.NET "My" not working as expected?

[DualBrain]

@cston and @KathleenDollard,

Here is an isolated example running on the most recent bits as far as I can tell (at least with regards to the Microsoft.VisualBasic side of things).

Module Program
Sub Main(args As String())
Console.WriteLine(My.Computer.Name)
Console.WriteLine((New Microsoft.VisualBasic.Devices.ServerComputer).Name)
Console.WriteLine(System.Environment.MachineName)
End Sub
End Module

The first line doesn’t work in .NET Core 3.0; however, the second and third lines do. Playing with the same code in the full .NET Framework, all three lines work and when you jump to the reference for My.Computer.Name, it goes to Microsoft.VisualBasic.Devices.ServerComputer.Name. I then jumped back over to the .NET Core source tree and that property simply returns System.Environment.MachineName. One thing I find interesting about this is it’s not a 1:1 map… how does My.Computer.Name map to a property inside of an instantiated instance of Microsoft.VisualBasic.Devices.ServerComputer? Some “magic” black-box stuff there?

So am I just missing something as far as how to "light up" the My side of things when working with a .NET Core 3.0 console project? Or is there some additional work that still has to be done beyond the work that has taken place within the Microsoft.VisualBasic namespace?

(BTW, @cston great work thus far!)

Thanks.

Cory Smith

[danmosemsft]

@DualBrain what does "doesn't work" mean exactly - missing method exception? wrong result?

[DualBrain]

The line:

Console.WriteLine(My.Computer.Name)

Will not compile (and should). As for the IDE, it show "red squiggles".

If you type My. the popup only shows InternalXmlHelper as a possible entry... no Computer, no User, no Forms, nothing else. I provided the example to demonstrate a common behavior and that the "underlying" pieces are indeed in place to allow My to work... it's just that My beyond the first "dot" is MIA.

On the flip side, it is possible to extend My... so at least there is that.

[DualBrain]

I meant to update the sample when I originally posted to be the following but got distracted with "the day job"...

Module Program
Sub Main(args As String())
Console.WriteLine(My.Computer.Name) ' <--- Will not compile, red squiggles.
Console.WriteLine((New Microsoft.VisualBasic.Devices.ServerComputer).Name) ' <--- What My.Computer.Name basically translates to...
Console.WriteLine(System.Environment.MachineName) ' <--- What the underlying code ultimately does.
End Sub
End Module

So I apologize for leaving that out of the original post.

[danmosemsft]

Ah right. I think My is a construct created by the VB compiler. @cston would have to answer why the compiler isn't handling it.

[cston]

@DualBrain, thanks for reporting this.

The .vbproj file for a .NET Core 3 Console app differs from the .vbproj for a .NET Framework 4.7 Console app:
.NET Core 3 Console app: -vbruntime*
.NET Framework 4.7 Console app: -sdkpath:<sdkpath> instead of -vbruntime, and additional define:_MyType=\"Console\"

Changing the .NET Core 3 project to replace -vbruntime* with -sdkpath:<sdkpath> or -vbruntime:<sdkpath>Microsoft.VisualBasic.dll, and adding define:_MyType=\"Console\" resolves the build error. (Changing .NET Framework 4.7 project to use -vbruntime* results in the same build error as reported above.)

@KathleenDollard, let's discuss how to resolve this issue.

[cston]

cc @jmarolf, @livarcocc

[cston]

Related issue: https://github.com/dotnet/sdk/issues/3379

[nguerrera]

Duplicate of https://github.com/dotnet/sdk/issues/2793

[nguerrera]

Reopening for second half of this: define:_MyType=\"Console\", the VB runtime part is tracked by #2793

[nguerrera]

So the define comes from this in the classic .csproj template

<MyType>Console</MyType>

And Window Forms projects have MyType=WindowsForms, and then WPF has MyType=Custom with a generated MyWpfExtension.vb added to the project.

@KathleenDollard I'll need your help here. Do we want to change the templates to match the framework templates on this or are we expecting the SDKs to do some magic here? Not sure how to magically do the WPF one where there is a generated file added to the project, though.

I think a default of MyType=Console in the SDK and then the WindowsDesktop SDK can override to MyType=WindowsForms for UseWindowsForms=true.

But how do we handle WPF. I see MyType=Windows as a possible value here, but not sure if that is sufficient for WPF?
https://github.com/dotnet/roslyn/blob/fab7134296816fc80019c60b0f5bef7400cf23ea/src/Compilers/VisualBasic/Portable/Symbols/EmbeddedSymbols/VbMyTemplateText.vb

Possibly this might be the best path forward:

1. Microsoft.NET.Sdk defaults to MyType=Console.
2. Close this issue and open a new one on Microsoft.NET.Sdk.WindowsDesktop to override defaults appropriately, work with Roslyn if any changes are needed there.

[nguerrera]

Combining with the workaround for #2793 the following is enough to get the program in this issue to build and run:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <MyType>Console</MyType>
  </PropertyGroup>

  <!-- Work around https://github.com/dotnet/sdk/issues/2793 -->
  <Target Name="SetVBRuntimePath" AfterTargets="ResolveAssemblyReferences">
    <PropertyGroup>
      <VBRuntime Condition="'%(ReferencePath.FileName)' == 'Microsoft.VisualBasic'">%(ReferencePath.Identity)</VBRuntime>
    </PropertyGroup>
  </Target>
</Project>

[nguerrera]

Discussed with @KathleenDollard and @cston. For the time being, we will assume that MyType remains unset by default and it is up to templates, project system, user to set it. So I will close this once the following works with the code in this isssue:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <MyType>Console</MyType>
  </PropertyGroup>
</Project>

And file an issue for the templates to include MyType.

[nguerrera]

Filed these issues for the templates:

• Console and Class library: https://github.com/dotnet/templating/issues/2006
• WPF: https://github.com/dotnet/wpf/issues/1230
• Windows Forms: https://github.com/dotnet/winforms/issues/1346

[DualBrain]

I'm assuming this still requires something else to be done; meaning that it's expected that this doesn't currently work in Preview6 for a Console app. If I'm correct on this, would you be able to guess as to when it (which preview for example) that this might be available?

Or will the following:

  <Target Name="SetVBRuntimePath" AfterTargets="ResolveAssemblyReferences">
    <PropertyGroup>
      <VBRuntime Condition="'%(ReferencePath.FileName)' == 'Microsoft.VisualBasic'">%(ReferencePath.Identity)</VBRuntime>
    </PropertyGroup>
  </Target>

Also be part of the templates as well... or is something else being done to "handle" that more automagically?

(Note: It does work in preview6 if I add both the MyType and Target portions. So thank you so much for providing this as a means to get My working immediately.)

[nguerrera]

I'm doing the equivalent of that target in the SDK "automagically". That will be in preview 8. Only MyType will be needed in the project once that's in, and the issues above track adding MyType to various VB templates.

[nguerrera]

Unfortunately VB "My" will not work in 3.0 after all. Some types like "Computer" are being removed from corefx in order to be able to find an appropriate higher level where they can finish their implementation with dependencies that are higher than the base shared framework (winforms).

This means that we have to default MyType to Empty and the build will fail if you try to set it to something else.

@KathleenDollard @cston Do we have a tracking issue for that elsewhere? I'd like to leave this closed as the work remaining would still be in the VB runtime library and project templates, and nothing remains in SDK.

[cston]

@nguerrera, see https://github.com/dotnet/winforms/issues/1632.