Failure in project reference target framework negotiation when ProjectReference items are duplicated

[dsplaisted]

Build A.csproj in the below example.

EXPECTED: Build succeeds
ACTUAL:

C:\git\vstest\tools\dotnet\sdk\2.2.0-preview1-007460\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(165,5): Assets file 'C:\git\vstest\src\Microsoft.TestPlatform.CrossPlatEngine\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v1.0'. Ensure that restore has run and that you have included 'netcoreapp1.0' in the TargetFrameworks for your project. [C:\git\vstest\src\Microsoft.TestPlatform.CrossPlatEngine\Microsoft.TestPlatform.CrossPlatEngine.csproj]

The duplicated ProjectReference appears to be interfering with the logic in _GetProjectReferenceTargetFrameworkProperties which is supposed to set SetTargetFramework on the AnnotatedProjects.

A.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net46;netcoreapp1.0;netstandard1.4</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\B\B.csproj" />
    <ProjectReference Include="..\B\B.csproj" />
  </ItemGroup>

</Project>

B.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net46;netstandard1.4</TargetFrameworks>
  </PropertyGroup>

</Project>

[dsplaisted]

@AndyGerlicher I'm not sure how important it is that a project with duplicate references build successfully, but I think we should at least have a good error message. Right now the failure mode has no relation to the root cause of the problem, and it was very difficult for @nguerrera and I to diagnose it.

[smadala]

This issue no more repro on windows with latest dotnet cli(.NET Command Line Tools (2.2.0-preview1-007853)). But on Ubuntu it is still causing build failure.

It will be very helpful if the error indicates the actual csproj rather than the projects referenced.

[nguerrera]

Just a note that it is also possible for this to manifest with failure to write to a file in use.

[michael-hawker]

This issue no more repro on windows with latest dotnet cli(.NET Command Line Tools (2.2.0-preview1-007853)). But on Ubuntu it is still causing build failure.

It will be very helpful if the error indicates the actual csproj rather than the projects referenced.

We've just been hitting this as well, really confusing. Our Windows builds were fine when we added a duplicate project reference (one hard-coded in our config - the other generated from other tooling we've built). However, it was failing to resolve properly on linux in our GitHub Actions CI on Ubuntu with dotnet build (as it would make it appear as if the reference dll was missing, which it was... [even though we had a project reference to the dependent project]).

In case it helps in the future looking at the binlog (attached msbuild.zip) it was found as a Project Reference in the evaluation phase here (the Converters/src project):

But then missing in the ResolveProjectReferences step:

So slightly different behavior than the original poster here, but end result of duplicated ProjectReference in project on a dotnet build on linux doesn't work, where same code/setup on Windows has no issues.

[michael-hawker]

This has larger implications on our workflow than I realized. We need to add the reference in some cases when we're not building everything for local development. However, one of the projects being built may or may not include the same project reference we need for our 'shell'.

Therefore, we have no way of knowing if a duplicate ProjectReference will be added within the target project that we're building around. This of course is fine on Windows locally, but will break when trying to build that single item within Codespaces...

[stan-sz]

This sounds like a task for #1777 or #804

As an interim, it is possible to write a custom target around CheckForDuplicateItems task (need this fix though, for correctness) to error on duplicate ProjectReferences in a project.

[michael-hawker]

@stan-sz not sure if a linter truly helps.

In our case, we're sucking a bunch of different projects together into a larger build, some of them may have references to the same project and need them to build themselves. It's just at the parent level that we're trying to build that now thinks there are multiple references:

graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D;

Loading

So, we can't remove the reference to D from either B or C as they need it to build.

At least I think that's what still going on here and is related to this underlying issue. I'm hitting this locally now trying to build a Windows App SDK/WinUI 3 app and seeing CS1704 An assembly with the same simple name has already been imported.