Cannot build VB .NET Core 3 library project without ContextValue

[nguerrera]

Repro steps

1. Get latest 3.0 preview 8 build of the SDK: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/3.0.100-preview8/dotnet-sdk-latest-win-x64.exe
2. mkdir repro
3. cd repro
4. dotnet new classlib --language VB --framework netcoreapp3.0
5. dotnet build

Expected result

Builds successfully

Actual result

vbc : error BC30002: Type 'Global.Microsoft.VisualBasic.MyServices.Internal.ContextValue' is not defined.

I believe this is coming from https://github.com/dotnet/roslyn/blob/fab7134296816fc80019c60b0f5bef7400cf23ea/src/Compilers/VisualBasic/Portable/Symbols/EmbeddedSymbols/VbMyTemplateText.vb#L355

I suppose there are two fixes:

1. Change the code spit in the compiler to not require this type when building a library. (In which case, this could be moved to dotnet/roslyn)
2. Add the type to Microsoft.VisualBasic.Core.dll

cc @danmosemsft @cston @KathleenDollard I believe this should be considered blocking for 3.0.

It is possible to work around this by setting VBRuntime=Embed or MyType=Empty in the vbproj, but that is effectively undoing other work that was done for VB in 3.0.

[paul1956]

Am I correct that this means that Visual Studio 16.3.0 Preview 2.0 is broken for VB Core 3.0 Applications? I can't build working libraries anymore. If so it would have been nice to know BEFORE I installed the update. Is there any workaround?

[cston]

@paul1956, would the work arounds from the bug description help? That is, add <VBRuntime>Embed</VBRuntime> or <MyType>Empty</MyType> to the .vbproj file.

[KathleenDollard]

Aaargghh! Sorry Paul.

@nguerrera where are we at on this? Is the problem in tasks/targets or something we insert in VS? I'm wondering if @paul1956 could uninstall .NET Core 3.0 Preview 8 and reinstall .NET Core3.0 Preview 7, or install a nightly build when this is fixed.

@paul1956 We did have to take changes that will result in a take back in .NET Core 3.0 Preview 9 which I expect will be in Visual Studio 16.3 Preview 3. We had to remove several types and the My system because they depend on WinForms and our previous approach of splitting types was shown to be heading for a very solid brick wall. You will still be able to do WinForms in the C# style, but not in the VB style until we get more work in.

[nguerrera]

I would recommend the following workaround in .vbproj over trying to move backwards or take a bleeding edge nightly build:

<PropertyGroup>
  <MyType>Empty</MyType>
</PropertryGroup>

[nguerrera]

That said, this should be fixed in Preview 9 daily build that you could get now from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/3.0.1xx/dotnet-sdk-latest-win-x64.exe

[paul1956]

@cston, @nguerrera <MyType>Empty</MyType> got rid of the errors and allowed the build, MyType=Empty as a constant did not, thanks for the clearer instructions. I have not checked if anything broke in the application. Thanks.

[KathleenDollard]

@paul1956 If you decide to try the nightly build, would you let us know whether this works without the Empty hack in Preview 9. We believe this will work fine, but it would be awesome to have confirmation.

[nguerrera]

Closing this issue as we can now build libraries without this type and there are other issues tracking porting missing types for general feature parity.

[paul1956]

@KathleenDollard
Visual Studio has 2 issues

MSBuild/Test has the second issue

C:\Program Files\dotnet\sdk\3.0.100-preview9-013908\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3277: Found conflicts between different versions of "System.IO.Pipes.AccessControl" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [

Despite the warning(s) all my tests pass and UI application using libraries also runs