RAR discovers new resource DLLs that aren't culture-related after custom-culture change

[rainersigwald]

An internal Microsoft team reached out to me to report a behavior change between .NET SDK 9.0.103 and 9.0.200. A new DLL was present in their output folder, which failed the build since they have an explicit "is anything unexpected appearing in our output" check.

Looking at the log, the first reference to the new Resources\xxxx.resources.dll file was in the referencing project's ResolveAssemblyReferences. Eventually we figured out that a custom tool used to create resources (not standard .NET resources but something custom). That tool (invoked via an <Exec) appears to have created the .resources.dll both before and after the SDK change, but it was ignored until #11000 stopped validating culture names in resource subdirectories:

msbuild/src/Tasks/AssemblyDependency/ReferenceTable.cs

Lines 965 to 981 in aff5455

	string satelliteFilename = subDirectories.Length > 0
	? reference.FileNameWithoutExtension + ".resources.dll"
	: string.Empty;
	foreach (string subDirectory in subDirectories)
	{
	// Is there a candidate satellite in that folder?
	string cultureName = Path.GetFileName(subDirectory);
	// Custom or unknown cultures can be met as well
	if (ChangeWaves.AreFeaturesEnabled(ChangeWaves.Wave17_14) || CultureInfoCache.IsValidCultureString(cultureName))
	{
	string satelliteAssembly = Path.Combine(subDirectory, satelliteFilename);
	if (_fileExists(satelliteAssembly))
	{
	// This is valid satellite assembly.
	reference.AddSatelliteFile(Path.Combine(cultureName, satelliteFilename));

Now, Resources is considered a culture and the .resources.dll file is discovered (and copied to the output), leading to customer surprise.