Unify the nullable reference type approaches

[jaredpar]

The sdk repo had a number of different approaches to how nullable reference types were, or were not, enabled in the code base. This spanned the range from project settings, to opt out in many files and even forcing opt in in other files. That makes it very difficult to look at an individual file and understand whether or not nullable reference type analysis is occurring.

This PR unifies the repository into a single approach. Every file has nullable reference type analysis enabled by default. Files that don't want this analysis declare so by adding #nullable disable at the top of the file. There were a few cases where the repo previously <Nullable>annotations</Nullable> and files in those projects were changed to have #nullable disable warnings if they contained any nullable annotations.

This is a largely mechanical change that was done with AI generated scripting. I went through all the files that were previously #nullable enable and verified that they have no #nullable directive after this change.

Note: this PR does not change which files did, or did not, have nullable analysis enabled. It just unifies the repo on a single approach for how to declare this.

[Copilot]

Pull Request Overview

This PR unifies the repository’s approach to nullable reference type analysis by ensuring that every file has consistent handling. The changes involve adding the "#nullable disable" directive at the top of multiple files, ensuring a single declarative approach to disable nullable analysis where needed.

Reviewed Changes

Copilot reviewed 656 out of 660 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Cli/dotnet/CommandDirectoryContext.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/CommandBase.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/CliUsage.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/CliTransaction.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/CliCompletion.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BundledTargetFramework.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/VBCSCompilerServer.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/RazorServer.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/RazorPidFile.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/MSBuildServer.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/IBuildServerProvider.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/IBuildServer.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/BuildServerProvider.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/BuildServer/BuildServerException.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/AutomaticEncodingRestorer.cs	Added "#nullable disable" at the start of the file
src/Cli/dotnet/AspNetCoreCertificateGenerator.cs	Added "#nullable disable" at the start of the file

Files not reviewed (4)

• Directory.Build.targets: Language not supported
• src/BuiltInTools/HotReloadAgent.Data/Microsoft.DotNet.HotReload.Agent.Data.Package.csproj: Language not supported
• src/BuiltInTools/HotReloadAgent.PipeRpc/Microsoft.DotNet.HotReload.Agent.PipeRpc.Package.csproj: Language not supported
• src/BuiltInTools/HotReloadAgent/Microsoft.DotNet.HotReload.Agent.Package.csproj: Language not supported

[jaredpar]

@baronfel the FullFramework: windows (x64) leg is failing in CI but I'm having trouble reproducing it locally. I've read through the YML and seems to be the key is having %TestFullMSBuild% be "true". That definitely impacts the execution of build.cmd but still not seeing the build failure locally. Any tips on how to reproduce?

[baronfel]

@jaredpar sadly no :( I have very little idea how to work with the Framework version of the repo. Maybe @joeloff or @marcpopMSFT know off the top of their heads?

[joeloff]

I don't use it often, though I did find a note I scribbled down that said modify TestCommandLine.cs and set UseFullFrameworkMsBuild to true

[marcpopMSFT]

It's failing in the build though rather than in the test run. The full framework leg I thought was only different in the actual test execution. I don't think we even use a different image so I'm not sure how it failed the build here but not one of the other windows legs.

D:\a_work\1\s\src\Cli\dotnet\Commands\Restore\RestoreCommand.cs(49,96): error CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. [D:\a_work\1\s\src\Cli\dotnet\dotnet.csproj]

[jaredpar]

Okay I figured out the reason for the CI error. There was a change merged into main that added nullable annotations into RestoreCommand.cs. Every job in the CI run except Full Framework Build started before the merge but that job started after. Hence all the other jobs succeeded but Full Framework Build hit the legitimate build error once it saw the change in main. That should all be fixed now.

[marcpopMSFT]

Okay I figured out the reason for the CI error. There was a change merged into main that added nullable annotations into RestoreCommand.cs. Every job in the CI run except Full Framework Build started before the merge but that job started after. Hence all the other jobs succeeded but Full Framework Build hit the legitimate build error once it saw the change in main. That should all be fixed now.

Wait, it's possible to have different legs build with different merge results with main? That seems non-ideal and super unreliable.

[jjonescz]

for future reference, if you want to build with Full Framework locally, you can just run .\eng\print-full-msbuild-path.ps1 which sets an environment variable that the rest of the sdk repo (at least tests, not sure about build) use to determine whether to use msbuild.exe or dotnet.exe

[jaredpar]

Wait, it's possible to have different legs build with different merge results with main?

Yes it is possible and can be pretty confusing.

[MiYanni]

To preface, here was the initial PR I made to try to "heard the cats" on nullable: #44936

After reviewing the approach here, I think this is a good idea. Here's why:

• Allows new source files to default as nullable
• Allows for converting individual files marked with #nullable disable over time as desired to nullable
• This PR doesn't require code changes
• All code-flow from servicing branches should "just work" with these changes, unless there were new files created which is rare

I do not plan on reviewing every file as 98% of them are adding #nullable disable to the top. But this approach gets my approval.