Artifacts Path Layout causes intermittent build failures when any projects involved in the build have the same _name_

[baronfel]

Describe the bug

Since ArtifactsPath uses the project name as the primary 'namespace' for outputs, as soon as you have a duplicate name you end up with race conditions in the projects that share the same name and/or projects that are downstream of them. Aspire hit this and fixed it with an explicit check that fails when there is a duplicate project name in dotnet/aspire#11587.

To Reproduce

• Create two projects in separate directories with the same project file name.
• Configure them to use Artifacts layout.
• Do a build.
• See that there is only one artifacts output directory.

[baronfel]

This will be rough to fix because we need a disambiguator, but adding a disambiguator makes working with the ArtifactsPath layout more frustrating. So we'd ideally not have the disambiguator enabled by default, but then we can't easily detect that we'd need the disambiguator.

This kinda feels like a thing where an SDK-shipped buildcheck would be able to flag the issue and suggest to the user that they do something to mitigate it.

cc @dsplaisted for better thoughts than mine 😄

[DamianEdwards]

Yeah I think an opt-in ability to disambiguate a project might be good enough here, so that there's flexibility on the project-level for how to resolve. The SDK could highlight the potential issue to the user via the buildcheck and then the user can decide how to the use the opt-in ability to fix it, e.g. set a property like:

<ProjectArtifactsOutputDirName>
  $(MSBuildProjectName)-$([MSBuild]::StableStringHash("$(MSBuildProjectFullPath)")
</ProjectArtifactsOutputDirName>

[Youssef1313]

Couldn't we have a solution-level MSBuild Target that produces an error in this scenario? https://github.com/dotnet/sdk/blob/main/src/Tasks/Microsoft.NET.Build.Extensions.Tasks/msbuildExtensions-ver/SolutionFile/ImportAfter/Microsoft.NET.Sdk.Solution.targets

The metaproj generated by MSBuild should have all the ProjectReferences so I imagine the needed info can be accessed in a target?

[Youssef1313]

One scenario to validate though is build dependencies in solution, as these produce a separate metaproj IIRC. e.g, in slnx:

    <Project Path="src/A/MyProj.csproj">
      <BuildDependency Project="src/B/MyProj.csproj" />
    </Project>

[Youssef1313]

$(MSBuildProjectName)-$([MSBuild]::StableStringHash("$(MSBuildProjectFullPath)")

I'm not sure if it's better to resolve the path relative to the directory containing the solution being built so that the build output is more stable if whole repo is moved to a different directory (either on same machine or entirely different machine)