Can't compile "Unmanaged constructed type" after deploying the latest master from Visual Studio

[lostmsu]

Version Used: 6de8558637d012340122c9849be633be3004ed9c

Steps to Reproduce:

1. Follow Roslyn Visual Studio 2019 build instructions
2. Launch RoslynDev instance of VS 2019
3. Clone https://github.com/losttech/TypeNum
4. Checkout fbd9ddba289e44dba9db172f58edc60692a8742c
5. Open TypeNum/TypeNum.sln
6. Try building solution

Expected Behavior: IDE does not show any errors Solution builds

Actual Behavior: IDE does not show any errors (which is correct) Build fails: error CS8377: The type 'N1<int>' must be a non-nullable value type, along with all fields at any level of nesting, in order to use it as parameter 'TNum' in the generic type or method 'Twice<TNum, T>'

Environment VS 16.0.0 RC.2 dotnet --version: 3.0.100-preview3-010431

Related

31374

dotnet/csharplang#1744

[jcouv]

A few things to try:

• Can you also try building the solution?
• Please add #error version in your code and let us know what diagnostic is produces (in IDE and Output window when building).

[lostmsu]

Can you also try building the solution?

That's what I did. (e.g. tried building TypeNum/TypeNum.sln) Or do you mean a different solution? The Roslyn one?

error version

Error List shows 42.42.42.42424, Output shows 3.0.19.15604 (7d31dd6e)

[jcouv]

Thanks. There are two version of the compiler involved: one is in the IDE (used for squiggles and Error List) and one for building. I just wanted to confirm which one failed.

The fact that the build output with #error version shows 3.0.xyz is likely the source of the problem. That version is a vanilla dev16 compiler, not the compiler you built locally. I'll let @RikkiGibson try to repro the scenario locally. Feels like it may be a deployment issue.

Just to double-check, to deploy your locally-built compiler you did something like:

• msbuild /v:m /m Roslyn.sln
• devenv /rootSuffix RoslynDev Let me know if that's not the case.

Something worth trying (which I usually do when I run into this sort of problems) is deleting the 16. ... RoslynDev folder under C:\Users\<user>\AppData\Local\Microsoft\VisualStudio (delete the RoslynDev hive) and re-running the build/deployment commands above.

[lostmsu]

Just to double-check, to deploy your locally-built compiler you did something like:

I just launched "Visual Studio Extension" from withing VS 2019 RC.

BTW, it is possibly relevant, that I have both VS 2019 RC and VS 2019 Preview installed. And the Preview was installed before VS 2019 RC.

In Local\Microsoft\VisualStudio I have 16.0_b76059e3RoslynDev and RoslynDev folders, the second is nearly empty (only has .\Settings).

[jcouv]

I just launched "Visual Studio Extension" from withing VS 2019 RC.

When you open Roslyn.sln, I'd expect "RoslynDeployment" to be set as the startup project, which can be launched ("Start without debugging" typically).

The deployment instructions also mention launching the "RoslynDeployment" project.

You should try that. I'm not sure that launching the "Visual Studio Extension" project would deploy all that's needed.

[lostmsu]

Sorry, you are correct, I am launching RoslynDeployment, which is selected by default: Updated the top post for clarity.

[jcouv]

No worries. I assume that you click on "Visual Studio Extension" to launch. Could you try "Start without debugging" (Ctrl+F5)? That's what I usually do.

(going offline for the night, ttyl)

[lostmsu]

Did that too. Same result. Night!

[jcouv]

I'm able to repro (following the repro steps in OP). In particular, I get compiler version '3.0.19.16207 (88ca01f7)' when I Build, which is unexpected (I'd expect 42.42.42.42424).

Tagging @jmarolf @jasonmalinowski to advise. I think this is a deployment/F5 issue.

[lostmsu]

Note, I added a checkout step with specific commit to repro, as I intend to continue working on that project.

[jcouv]

@lostmu FYI, I updated OP with a more self-contained repro (small code sample).

I reverted OP instructions because the problem did not repro with a .NET Framework project. It only repro'ed with a Core project.

3. In a new project, use the "unmanaged constructed type" feature. For instance, paste code below in a .NET 4.7 Core 3.0 project (so ValueTuple is available).

public struct MyStruct
{
    public (int, int) field;
}
public class C
{
    public void M<T>() where T : unmanaged { }
     public void M2()
    {
        M<MyStruct>();
        M<(int, int)>();
    }
}

[jmarolf]

@jcov I originally created this PR to try and fix issues like this: https://github.com/dotnet/roslyn/pull/33732 I you can step through the extension in a debugger you can confirm that it is finding the commandline compiler.

[jcouv]

I debugged the "Roslyln.Compilers.Extension" project and it creates three files:

• C:\Users\jcouv\AppData\Local\Microsoft\MSBuild\Current\Imports\Microsoft.Common.props\ImportBefore\Roslyn.Compilers.Extension.VisualStudio.16.0_dca6dd93RoslynDev.props
• C:\Users\jcouv\AppData\Local\Microsoft\MSBuild\Current\Microsoft.CSharp.targets\ImportBefore\Roslyn.Compilers.Extension.VisualStudio.16.0_dca6dd93RoslynDev.targets
• C:\Users\jcouv\AppData\Local\Microsoft\MSBuild\Current\Microsoft.VisualBasic.targets\ImportBefore\Roslyn.Compilers.Extension.VisualStudio.16.0_dca6dd93RoslynDev.targets

They seem correct as far as I can tell.

Two suspicious things so far:

• none of the breakpoints I set in SetGlobalGlobalPropertiesForCPS got hit
• the breakpoints I set are only hit when I run Build the second time (the first build succeeds without any breakpoints in the extension getting hit)

[RikkiGibson]

@jcouv @jmarolf does this issue still need attention?

[jcouv]

It does. From my observations above, Jon said it's likely a MEF issue, so he'll take next steps of investigation.

[lostmsu]

@jcouv @jmarolf just wanted to see if there's any progress on that issue, as I'd like to try again!