Version Used:
Not sure, using Visual Studio 2018 Preview 1.0 and C# 8
Steps to Reproduce:
Expected Behavior:
VS shows the normal tested/untested passing/failing icons based on the unit test results.
Actual Behavior:
It fails to build during the Live Unit Testing with error: "error CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' context".
When the classes using nullable references have the "#nullable enabled" declaration it fails with this error:
[20:03:02.349 Error] - FatalError - System.ArgumentException: Inconsistent language versions
Parameter name: syntaxTrees
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CommonLanguageVersion(ImmutableArray`1 syntaxTrees)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation..ctor(String assemblyName, CSharpCompilationOptions options, ImmutableArray`1 references, CSharpCompilation previousSubmission, Type submissionReturnType, Type hostObjectType, Boolean isSubmission, ReferenceManager referenceManager, Boolean reuseReferenceManager, SyntaxAndDeclarationManager syntaxAndDeclarations, AsyncQueue`1 eventQueue)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.Update(ReferenceManager referenceManager, Boolean reuseReferenceManager, SyntaxAndDeclarationManager syntaxAndDeclarations)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.AddSyntaxTrees(IEnumerable`1 trees)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CommonAddSyntaxTrees(IEnumerable`1 trees)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.CompilationComparer.GetUpdatedCompilation(Compilation compilation, CommandLineArguments arguments, Logger logger, BuildDifference& differences)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.EmitHelper.<EmitAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.BuildService.<EmitSingleProjectAsync>d__51.MoveNext()
Moved from dotnet/csharplang:
When using C# 8 nullable references with Visual Studio 2019, the Live Unit Testing feature doesn't work. The build always fails with error messages like "error CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' context.". I realize this is probably because I have the "Treat warnings as error" turned on but the solution builds fine as I have the nullable references turned on for all projects in the .csproj file.
Adding "#nullable enable" to the files with nullable references changes this error to:
[20:03:16.156 Error] - FatalError - System.ArgumentException: Inconsistent language versions
Parameter name: syntaxTrees
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CommonLanguageVersion(ImmutableArray`1 syntaxTrees)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation..ctor(String assemblyName, CSharpCompilationOptions options, ImmutableArray`1 references, CSharpCompilation previousSubmission, Type submissionReturnType, Type hostObjectType, Boolean isSubmission, ReferenceManager referenceManager, Boolean reuseReferenceManager, SyntaxAndDeclarationManager syntaxAndDeclarations, AsyncQueue`1 eventQueue)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.Update(ReferenceManager referenceManager, Boolean reuseReferenceManager, SyntaxAndDeclarationManager syntaxAndDeclarations)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.AddSyntaxTrees(IEnumerable`1 trees)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CommonAddSyntaxTrees(IEnumerable`1 trees)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.CompilationComparer.GetUpdatedCompilation(Compilation compilation, CommandLineArguments arguments, Logger logger, BuildDifference& differences)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.EmitHelper.<EmitAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.CodeAnalysis.LiveUnitTesting.BuildManagement.BuildService.<EmitSingleProjectAsync>d__51.MoveNext()
I have C# 8 set as the language for all projects.
I've been asked to tag @ManishJayaswal
@jcouv
Hum, I wonder if this problem occurs with all C# 8 features.
The problem might be because of the special situation we have with language versions:
default
still means 7.0latest
means 7.3latest
was greater than all numbered versions, but for the moment 8.0 is higher than latest
...So if LUT code is using any of those labels in a project that uses C# 8.0 beta, there could be an unexpected situation.
tagging @drognanar to take a look.
I don't supposed there is any solution to this issue? I just ran into this myself after spending an ungodly amount of time annotating my code.
There issue should be fixed and a fix should be available with the 16.3 release
Unfortunately there is no solution to this, unless you want to install a preview release of VS, that might already include the fix.
I鈥檓 on .3 preview 2 already. Is there a super secret build?
I assume it means that you need to wait for preview 3.
The internet is no place for jokes:-) I just suppressed the warning.
I also have this issue with MSTest and VS2019 16.2.5 (stable)
I still have this issue on 16.4.0 (preview 1). However, for me it also fails to build, breaking unit testing completely. This is because I also get the following error along with the warnings:
error CS8627: A nullable type parameter must be known to be a value type or non-nullable reference type. Consider adding a 'class', 'struct', or type constraint.
This comes from a line of code declaring a generic method with an out T? parameter, which works fine when nullable contexts are working in normal compilation outside live unit testing.
public bool TryGet<T>(int id, out T? result) where T : MyBaseClass
I see the same in 16.3.3.
Reproduced in 16.3.5, any known workarounds?
Update: Same for 16.4.0 Preview 2
you're right, the previous fix that I believed was related to this didn't resolve the issue.
I merged in a fix on Friday so it will be available with the next preview of 16.4.
@drognanar It is fixed in 16.4.0 Preview 4.0
Thx!
Cool. Closing this issue then
Most helpful comment
you're right, the previous fix that I believed was related to this didn't resolve the issue.
I merged in a fix on Friday so it will be available with the next preview of 16.4.