Compare file identities instead of counts in BuildFailureLogInvariant

[AR-May]

What happens today

Test assemblies run in parallel as separate processes. BuildFailureLogInvariant counts MSBuild_*.txt files across several temp locations at the start of every test and asserts the count is unchanged at the end.

Counting is fragile: any file that appears or disappears between the two scans changes the result, whichever process caused it.

• A file that was present at the start is gone at the end. The count drops and the test fails. The loop only inspects files that appeared, never files that vanished, so it cannot recognise the file as harmless — the only output is Expected: 2, Actual: 1.
• One file added and one file removed cancel out. The count matches, and a genuine crash dump goes unreported.

The fix

Compare file identities instead of counts. Record the file names at test start, and at the end look only at names that were not there before.

A deleted file was on the original list, so it can never appear as a new name — deletions can no longer fail the test. A crash dump is always a new name, so it can no longer be cancelled out.

Both existing filters (clean node shutdown, communication traces) are unchanged, so abnormal shutdowns still fail as they do today. The failure message now names the files and includes the PID and timestamps.

Two follow-ons in the same area

• Case-insensitive comparison. GetMSBuildLogFiles already de-dupes with InvariantCultureIgnoreCase, while Except used the ordinal default, so the two disagreed. These paths are case-insensitive on Windows, so differing casing between the two directory scans would make a file look new and fail the test. This cannot mask a crash: a dump name carries a PID and a GUID, so it cannot collide with a baseline file by case alone.

• Tolerate a file being deleted before it is read. File.ReadAllText ran unguarded between the glob and the delete. If the file is removed in that window, ReadAllText throws FileNotFoundException out of AssertInvariant, failing the test with a stack trace rather than a clean assert — the same fragility as above, with an uglier failure mode. DeleteNoThrow already swallowed IO errors, so only the read was exposed. A file that has vanished is skipped, because whichever process deleted it read it first and will report it; a file that is present but unreadable is still reported, because it cannot be recognised as benign and must not be silently dropped.

If a dump is observed and deleted by a process other than the one that produced it, the failure surfaces there rather than on the test that caused it. Nothing here changes that. The named-file message, with the PID and the timestamps, is what makes that diagnosable the next time it fires.