Enable #nullable enable in SolutionBuilder.cs

[Copilot]

SolutionBuilder.cs lacks nullable annotations, hiding potential null-reference issues at compile time.

• Add #nullable enable as the first line
• SolutionPath → string? (never set in constructor, always via object initializer)
• SolutionName → default = "" (constructor assigns it, default satisfies the compiler)
• Add ArgumentNullException.ThrowIfNull(SolutionPath) in Save() and BuildProject()
• Guard Directory.Delete in Dispose with string.IsNullOrEmpty(SolutionPath)
• No ! (null-forgiving operator) used

Note: used string.IsNullOrEmpty() rather than the .IsNullOrEmpty() extension method because Xamarin.ProjectTools doesn't reference the NullableExtensions class — consistent with all other usages in this project.

[Copilot]

Pull request overview

Enables nullable reference type analysis in the SolutionBuilder test helper to surface potential null-reference issues at compile time, and adds runtime guards where SolutionPath is required.

Changes:

• Added #nullable enable to opt the file into full nullable analysis.
• Annotated SolutionPath as nullable and provided a non-null default for SolutionName.
• Added null guards for SolutionPath in Save()/BuildProject() and tightened cleanup conditions in Dispose().

Comments suppressed due to low confidence (3)

src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Common/SolutionBuilder.cs:27

• ArgumentNullException.ThrowIfNull (SolutionPath) doesn’t make subsequent uses of the property non-nullable for the compiler (and the property could change between reads). Consider capturing to a local (var solutionPath = SolutionPath; ThrowIfNull (solutionPath);) and using the local for all Path.Combine/WriteAllText calls in this method to avoid nullable warnings and double-evaluation.

		public void Save ()
		{
			ArgumentNullException.ThrowIfNull (SolutionPath);
			foreach (var p in Projects) {
				using (var pb = new ProjectBuilder (Path.Combine (SolutionPath, p.ProjectName))) {

src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Common/SolutionBuilder.cs:72

• Same pattern here: after ThrowIfNull (SolutionPath), subsequent references to the SolutionPath property are still string? from the compiler’s perspective. Capture to a local once, validate it, and use the local for Path.Combine/BuildInternal to avoid nullable warnings and ensure a consistent value is used.

		public bool BuildProject(XamarinProject project, string target = "Build")
		{
			ArgumentNullException.ThrowIfNull (SolutionPath);
			BuildSucceeded = BuildInternal(Path.Combine (SolutionPath, project.ProjectName, project.ProjectFilePath), target, restore: project.ShouldRestorePackageReferences);
			return BuildSucceeded;

src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Common/SolutionBuilder.cs:102

• !string.IsNullOrEmpty (SolutionPath) followed by Directory.Delete (SolutionPath, ...) re-reads the nullable property; this can still produce nullable warnings and allows the value to change between the check and the delete. Capture SolutionPath to a local variable, check the local, and pass the local into Directory.Delete.

		protected override void Dispose (bool disposing)
		{
			if (disposing)
				if (BuildSucceeded && !string.IsNullOrEmpty (SolutionPath))
					try {
						Directory.Delete (SolutionPath, recursive: true);
					} catch (Exception) {