Add resource validation tests to prevent missing resource string errors

[Copilot]

• Create a test to verify all resource strings used in code exist in .resx files
  • Analyze the approach: scan assemblies for resource string references
  • Create test infrastructure to load and parse .resx files
  • Create test to extract resource references from source code using regex
  • Verify the test works on Microsoft.Build.dll (passing ✅)
  • Verify the test works on MSBuild.dll (passing ✅)
  • Address missing resources found by tests:
    • Tasks assembly: 12 missing resources in XamlTaskFactory (.NETFramework-only code) - documented with Skip
    • Utilities assembly: 1 missing resource (Message.InvalidImportance) - real bug documented with Skip
  • Add comprehensive documentation to test class
  • Add helper comments for extending tests to other assemblies
  • Run tests to ensure they work correctly (2 passing, 2 skipped)
  • Verify full build still works
  • Fix CS8604 nullable reference warning

Summary

Successfully implemented resource validation tests to prevent issues where code references resource strings that don't exist in .resx files.

What was added:

• New test file: src/Build.UnitTests/Resources_Tests.cs (275 lines)
• Test coverage: 4 test methods covering the main MSBuild assemblies
  • ✅ Microsoft.Build (passing)
  • ✅ MSBuild (passing)
  • ⏭️ Microsoft.Build.Tasks.Core (skipped - 12 missing resources documented)
  • ⏭️ Microsoft.Build.Utilities.Core (skipped - 1 missing resource documented)

How it works:

1. Parses .resx files to extract all available resource names
2. Scans C# source files using regex patterns to find resource string references
3. Validates that all referenced resources exist in the corresponding .resx files
4. Provides detailed output showing missing resources when validation fails

Benefits:

• Prevents runtime errors from missing resources
• Catches resources in wrong assemblies (cross-assembly references)
• Documents known issues for future resolution
• Easy to extend to additional assemblies
• Helps prevent issues like MSB4018: The "CreateItem" task failed unexpectedly, MSB0001: Internal MSBuild Error: Missing resource 'GlobExpansionFailed' #12334, Internal MSBuild Error: Missing resource 'RestoreComplete' on latest nightly sdk #11515, MissingRestorePropertyError doesn't exist #7218, Creating a Microsoft.Build.Evaluation.Project with an SDK fails with an "Internal MSBuild Error" #2997, [Bug]: TerminalLogger "on" and "off" are not recognized, results in resource errors. #9150

Recent fix:

• Fixed CS8604 nullable reference warning by adding null-forgiving operator

Original prompt

---

This section details on the original issue you should resolve

<issue_title>test that all used resources in code are present in resource files</issue_title>
<issue_description>Related to preventing issues like #12334 #11515 #7218 #2997 #9150

Most recently the issue was that the resource was accessible from multiple code paths (the class was compiled to 3 dlls) but tested only in one, leading to errors. A test case validating that resource files are matching what is used in a given dll would catch these.</issue_description>

<agent_instructions>please add test coverage based on the plan given by rainersigwald in the last comment</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@rainersigwald I think an analyzer would make a lot of sense--we have

msbuild/src/Shared/ResourceUtilities.cs

Lines 436 to 444 in e67b64e

	/// <summary>
	/// Verifies that a particular resource string actually exists in the string table. This will only be called in debug
	/// builds. It helps catch situations where a dev calls VerifyThrowXXX with a new resource string, but forgets to add the
	/// resource string to the string table, or misspells it!
	/// </summary>
	/// <remarks>This method is thread-safe.</remarks>
	/// <param name="resourceName">Resource string to check.</param>
	[Conditional("DEBUG")]
	internal static void VerifyResourceStringExists(string resourceName)

but it clearly hasn't done the trick--mostly because we don't have APIs to do all of the various conditions, so we have a lot of resource-logging calls that don't happen at all in normal operation.</comment_new>
<comment_new>@rainersigwald

But I'm not sure how to propagate the list from the analyser to the test — IIRC file I/O in analysers is not recommended.

Maybe generate a class per assembly that just has a list of the strings, internal to tests? Or pass the .resx files to the analyzer as additionalfiles and check directly?</comment_new>

Fixes #12413

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[dotnet-policy-service]

Hello @@copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.

[YuliiaKovalova]

@copilot resolve the issue
src\Build.UnitTests\Resources_Tests.cs(203,35): error CS8604: (NETCORE_ENGINEERING_TELEMETRY=Build) Possible null reference argument for parameter 'item' in 'bool HashSet.Add(string item)'.

[Copilot]

@copilot resolve the issue
src\Build.UnitTests\Resources_Tests.cs(203,35): error CS8604: (NETCORE_ENGINEERING_TELEMETRY=Build) Possible null reference argument for parameter 'item' in 'bool HashSet<s...

Fixed in commit a7a17ea by adding the null-forgiving operator (!) to line 203, which resolves the CS8604 warning while maintaining the null check on line 201.