@chsienki @jaredpar What types of projects does this impact? Is it all legacy projects?

@jasonmalinowski Any legacy project with an analyzer reference that requests project properties / metadata. It won't run until you add an analyzer that requests it (the roslyn ones do). But we evaluate the targets file in a different order for legacy projects, meaning the IntermediateDir hasn't been set yet, leading to the file being placed at the root instead.

"with an analyzer reference that requests project properties / metadata."

At this point do we have any inbox ones? My concern here is whether this fix needs to go into 16.8.

Hmm, I don't think it happens on the inbox ones, but I'm not sure exactly what we ship there. Right now on a file new project (.NET Framework) I don't see the issue until I explicitly add the roslyn analyzers.

@jasonmalinowski The plan is to take this for 16.9 and see how much feedback we get. If needed we can back port it to 16.8 with low risk as we'll have 16.9 to prove it out.

@chsienki: sounds good. I don't have a good sense of widespreadness either, but maybe this is worth getting into the 16.8 release notes or something that if you see this file, don't check it in.

I have the same issue with all Umbraco projects. Would be nice to see it fixed in 16.8 tbh.

@chsienki was this fix multi-targeting aware? I'm seeing race conditions in a project with 2 TargetFrameworks value where I get this error:

C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\Roslyn\Microsoft.Managed.Core.targets(191,5): error : The process cannot access the file 'e:\git\ssms\obj\Sql\ssms\core\QueryStoreModel\Debug\
Microsoft.SqlServer.Management.QueryStoreModel.GeneratedMSBuildEditorConfig.editorconfig' because it is being used by another process. [e:\git\ssms\Sql\ssms\core\QueryStoreModel\Microsoft.SqlServer.Management.QueryStoreMo
del.csproj::TargetFramework=net6.0]

I'd expect the file to be output to a TargetFramework-specific folder.

@shueybubbles It just uses the $(IntermediateOutputPath) to place the file. I would expect that to be different for different target frameworks, otherwise lots of access violations are likely to occur, not just this one.

Would you be able to share a binlog of your build that we can take a look at, or provide a simple repro? https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Providing-Binary-Logs.md

I see it working fine on our repo where all the projects are multi-targeted. In our repo where 99% of the projects have a single <TargetFramework> and only one project has <TargetFrameworks> with 2 values, that single project has the race. Both repos set <BaseIntermediateOutputPath> the same way. Maybe there's some weird interaction with dirs.proj that includes a mix of projects. If I find time I can try to create a reasonable sized repro.

we had a props file turning off AppendTargetFrameworkToOutputPath, the multitargeting project had to turn it on. thx