Stop overbuilding SemanticSearch.ReferenceAssemblies

[ViktorHofer]

Fixes dotnet/source-build#4390

cc @jaredpar

[tmat]

@ViktorHofer Thanks for the fix! We couldn't figure out what the issue is.

[tmat]

@ladipro How come msbuild lock detection was not able to find out that the file is locked by msbuild itself? Is it missing anything?

[ViktorHofer]

Feel free to merge. I don't have permissions.

[ladipro]

@ladipro How come msbuild lock detection was not able to find out that the file is locked by msbuild itself? Is it missing anything?

Competing writes to obj files, such what's in the description of the referenced issue, come from CSC so that's outside of MSBuild; it would have to be implemented in the compiler. For files in bin, so typically copying with the Copy task, my guess is that the operation is too fast that by the time the process detection logic runs, the file is no longer locked.

As mentioned in the issue, we're working on a double-writes analyzer. Interestingly though, binlog viewer already has double-writes analysis and it didn't catch this. It deserves a closer look because we were going to model MSBuild analysis after the viewer.

[ladipro]

Oh yes, currently the output path itself is used as a key which explains why it doesn't detect double writes in this case. I would naively expect the data to live in a list (i.e. no need to de-dup with a HashSet). Cc @KirillOsenkov for insights.

https://github.com/KirillOsenkov/MSBuildStructuredLog/blob/b56ebfb2caea11a3ffad279aa25ddd0f67a115da/src/StructuredLogger/Analyzers/DoubleWritesAnalyzer.cs#L72,L96

[tmat]

@ladipro Makes sense in this case - I think we already have a work item to expose the process locking detection logic to tasks, so that csc could also report the process name using msbuild APIs.

[KirillOsenkov]

I filed a viewer bug KirillOsenkov/MSBuildStructuredLog#779 to deal with this case.