Closed RussKie closed 4 years ago
Tagging @jcouv
I've encountered this situation at some point in the roslyn
repo. As far as I could tell, it was due to two different versions of the analyzer being used in different contexts (one in the build from IDE and one from build from command-line).
I'd try to get a structure log from the scenario where the last errors occur and double-check what binaries/version of the analyzer is being used.
@jcouv feel free to ping me on teams if you need more info.
@jcouv @RussKie has this been resolved?
Not yet. I was away for a few days. I'm still trying to debug the failure.
I've set up my local machine to repro with a locally built PublicAPI analyzer package, and instrumented the code with Debugger.Launch()
, but unfortunately that's not prompting me to attach a debugger... :-(
Let me know if you have any tips or other ways to debug this sort of issue.
After running build.cmd
, I looked at the binlog file and extracted the csc command-line to repro the issue.
Interestingly, I noticed that changing the version of the csc binary I used caused the issue to get resolved.
For instance, this one works, using latest compiler bits (built locally):
D:\repos\winforms\.dotnet\dotnet.exe exec "D:\repos\roslyn\artifacts\bin\csc\Debug\netcoreapp3.1\csc.dll" /noconfig @repro.rsp
This one also works (recent compiler bits, part of VS 16.6p1):
"C:\Program Files (x86)\Microsoft Visual Studio\2019\IntPreview\MSBuild\Current\Bin\Roslyn\csc.exe" /noconfig @repro.rsp
But this one fails (complaining about declared API):
D:\repos\winforms\.dotnet\dotnet.exe exec "D:\repos\winforms\.dotnet\sdk\5.0.100-alpha1-015536\Roslyn\bincore\csc.dll" /noconfig @repro.rsp
Looking at D:\repos\winforms\.dotnet\sdk\5.0.100-alpha1-015536\Roslyn\bincore\csc.dll
I see that it is version 3.4 of the compiler, compared to C:\Program Files (x86)\Microsoft Visual Studio\2019\IntPreview\MSBuild\Current\Bin\Roslyn\csc.exe
which has version 3.6
The implementation of nullability was only completed/shipped in version 3.5 of roslyn (corresponding VS 16.5), so I suspect this is the problem.
To use #nullable enable
in the publicAPI file, I think that you need to use version 3.5 of the compiler. At least, I verified using version 3.6, which works for sure
I'm not sure how to update the version of roslyn used in the winforms repo, as I didn't find an entry in eng\Versions.props
.
Do you know how to do it?
Thank you @jcouv for the investigation.
Now when you explained it, the results are making sense, Windows Forms is pinned a very old version of Microsoft.NETCore.App
due to a blocking dependency in WPF on a C++ toolset (which is being worked on by @tgani-msft et al).
@vatsan-madhavan @mmitche @AdamYoblick do you know if it is possible to use a newer version of Roslyn while remain pinned to Microsoft.NETCore.App
?
@jaredpar You mentioned there is a setting UseSomethingSomethingToolset
to reference a specific version of roslyn rather than that in the SDK. What is the name of that setting? Would you recommend it in this scenario?
You mean using a newer version of Roslyn to build dotnet/winforms? Maybe @tmat would know.
My guess is that you'll have to get into the weeds of how build-tooling works and override it yourself.
See https://github.com/dotnet/arcade/blob/master/Documentation/InfrastructureEcosystemOverview.md
Looks like we are unable to update to the latest runtime - blocked by by the C++ toolset issue that blocks WPF.
@RussKie Any progress? I'm not sure we want to keep this issue opened on analyzers at this point.
I think it is done. Thank you
Analyzer package
Microsoft.CodeAnalysis.PublicApiAnalyzers
Package Version
3.0.0-beta2.20077.2
Diagnostic ID
RS0017
Repro steps
error RS0037: PublicAPI.txt is missing '#nullable enable', so the nullability annotations of API isn't recorded.
error RS0036: Symbol 'Equals' is missing nullability annotations in the declared API.
Expected behavior
Actual behavior