error CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' a nnotations context.

[smoothdeveloper]

I'm trying to use the <Nullable>enable</Nullable> feature in a project having "warning as errors" (which I need to keep), but obviously it doesn't compile until I fix all the code, which I can't do.

I want to fix some of the code with annotations and without having <Nullable>enable</Nullable>, be able to keep on my journey maintaining C# code, only enabling it sporadically.

Context:

When I do this, which is having few nullable annotations, but the feature disabled, I get

error CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' a
nnotations context.

Which breaks my expectation that we want null safe code at some point, without a big bang change, and without having to single handedly put pragma in all the files (1 per class roughly) of a project.

What was the motivation for this error?

Is the feature only geared toward "new project will be null safe sometimes but old projects need to do big bang editing of all files at once"?

I'm not inclined to sprinkle "#nullable" pragmas in thousands of files, one by one, and then again, remove those, in thousands of files when the code reach the state of "null references all annotated".

Am I missing something?

Edit: basically I get the feeling I'm getting punished for daring to use "warning as error" and trying to get familiar with the null annotation syntax by starting using the annotations without enabling the feature.

Solution:

use

<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.csproj'">
	<LangVersion>latest</LangVersion>
	<WarningsNotAsErrors>$(WarningsNotAsError);8632;8618;8600;8602;8625</WarningsNotAsErrors>
	 <Nullable>warnings</Nullable>		
</PropertyGroup>

[yaakov-h]

Have you checked out the <WarningsNotAsErrors> option for your csproj?

You could also try <Nullable>annotations</Nullable> or any of the other options.

[smoothdeveloper]

Thanks @yaakov-h, so it appears that this is in fact a warning, which I couldn't distinguish due to "warn as error".

I wasn't aware of <WarningsNotAsErrors/>, seems like it would allow me to enable the feature in my warning clear projects.

Suggestions:

• report the warning as error errors as "error from warning" or something like this
• maybe if this warning is worth anything, it could point to WarningNotAsErrors feature in case it is raised as an error

The later point would be really user friendly to those that have the stringency to enable warning as errors, it would make me feel C# is friendly, by telling me how to progress on the "null safer world" journey.

[smoothdeveloper]

@yaakov-h I've played a bit with the permutations, and it seems I can get what I like with what I've put as a solution in the top level post.

[smoothdeveloper]

I'm seeing issues with pre dotnet SDK project files, I'm in a large solution with a mix of both and despite the nullable feature picks up, the WarningsNotAsErrors property doesn't seem to be.

What is the recommended approach to make progress in mixed SDK project format solution?

I can't easily upgrade the projects and I want to rely on Directory.Build.props rather than having to edit all .csproj files and keeping them in consistent shape.

[smoothdeveloper]

@jnm2 appreciate the summary, thanks!

I've already followed up with my peers so we put more efforts in migrating to new project format, but this requires lots of care / time / $, and this prevents us from making progress on the nullable reference stuff.

While I could understand better the motives from Microsoft, this is overall sad, because, even many years from now, unless VS stops supporting old project format, there will still be many .csproj in old format, and the code under it will basically not have much chance to leverage null flow analysis.

I'm wondering if there is a workaround still, passing the arguments to csc, I'll investigate a bit.

[jnm2]

IIRC I tried <ProvideCommandLineArgs> which has an effect in SDK-style projects but IIRC not legacy projects.

[smoothdeveloper]

@jnm2 I was looking to investigate if there is an equivalent to fsproj <OtherFlags/> that work in old .csproj and how that would play with

-warnaserror[+|-]             Report all warnings as errors
-warnaserror[+|-]:<warn list> Report specific warnings as errors
                              (use "nullable" for all nullability warnings)
-warn:<n>                     Set warning level (0 or higher) (Short form: -w)
-nowarn:<warn list>           Disable specific warning messages
                              (use "nullable" for all nullability warnings)
-ruleset:<file>               Specify a ruleset file that disables specific
                              diagnostics.
-errorlog:<file>[,version=<sarif_version>]
                              Specify a file to log all compiler and analyzer
                              diagnostics.
                              sarif_version:{1|2|2.1} Default is 1. 2 and 2.1
                              both mean SARIF version 2.1.0.
-reportanalyzer               Report additional analyzer information, such as
                              execution time.
-skipanalyzers[+|-]           Skip execution of diagnostic analyzers.

[jnm2]

I can only recommend https://msbuildlog.com and say good luck, may you succeed where I failed :D (I didn't want to create my own replacement for the Csc task.)

[yaakov-h]

My team tried to use nullable in the old project system but found it so unworkable that we ended up moving all annotated code to the new sdk.

[theunrepentantgeek]

It's not clear from the thread so far whether you are using #nullable individually on each specific warning occurrence or once per file.

For gradual migration, I've added #nullable enable to the top of each file as I've made other feature/bug changes, addressing issues as they came up.

Have you tried this?

[smoothdeveloper]

@theunrepentantgeek sorry if this wasn't clear:

• I do not want to use individual files pragmas (too many files, too fine grained)
• I rather have the warnings as warnings (in my warn as errors enabled projects) by flicking a few properties in Directory.Build.props once in a while when I want to make inroads in changing the code, first by putting annotations everywhere (and ignoring all warnings), second (much later) by adjusting the code so it becomes "null sound"

I'm sure the C# team has spent extraordinary amount of pondering all options and making the right choices and giving lots of options.

In my case: large C# codebase (from V1 of language) with mixed project format and given how we work on the code, I'd not like to use the pragma route (which is great and applicable for sure), but just "full on warnings" to adjust few type annotations, then discarding the option again, rince and repeat sparingly to not turn this into a big bang project.

Once a first pass of type annotation is done, and everyone is confident in "how do we annotate our stuff/how does C# work with nullable ref in our codebase", I'll think more about making the warning persistent or turn them into errors, likely project by project.

Hope this clarifies, and I really appreciate the feedback, as much as null sound C# code 🙂