Conditions in Directory.Build.props fail

[Lakritzator]

While trying out the most recent changes which allow benchmarking with dotnet core 3.0 desktop project, which btw, work GREAT, I noticed that when running BenchmarkDotNet I get errors for Tasks which should not run!

Those tasks have conditions which are normally not met but for the benchmark project they did.
I deleted the tasks, the benchmark ran without issues.

The cause was this ItemGroup:

  <ItemGroup Condition="!$(MSBuildProjectName.Contains('Test')) And !$(MSBuildProjectName.Contains('Demo'))">
    <PackageReference Include="PdbGit" Version="3.0.41">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>
  </ItemGroup>

While thinking about this, I noticed that the conditions are on the MSBuildProjectName. I believe that the temporary generated projects get a GUID as name, which causes my condition to return "true" (does not contain Test).

The workaround for me, is to delete the ItemGroup manually, which is okay for now.

I wanted to discuss a possible solution, while I believe there is no perfect solution I was hoping for a compromise.

I would suggest that we change the project names to have the original name in it, extended with the GUID. The main question is how, and this should be documented.

Suggestions:

• MSBuildProjectName-GUID
• GUID-MSBuildProjectName

Maybe you have some other ideas?

I will be more than happy to supply an example repository if this helps, but I could imagine that the case is quite clear? I can also take a look at writing a PR, I just wanted to get into a small discussion before doing so, not that things move into the wrong direction.

[timcassell]

I think we could do {OriginalProjectName}_bdn_partition_{BuildPartition.Id}. Since each build will go into their own isolated directory (in #2393), we won't need to use a guid. Guid is already used for the project directory (if KeepFiles is not enabled), so it's redundant.