Msbuild: Solution dependency leads to error MSB4057: The target "GetTargetPath" does not exist in the project

[bording]

There is a problem with solution dependencies that I believe was introduced with MSBuild 15.9, and is also a problem with 16.0.

The following scenario causes the problem;

• There is a project that has <GeneratePackageOnBuild>true</GeneratePackageOnBuild> set
• It has a solution dependency on a second project, and that project is multi-targeted.

Steps to reproduce

Build the attached project with MSBuild.exe or dotnet build: GetTargetPathRepro.zip

Expected behavior

The solution should compile without errors.

Actual behavior

The following error occurs:

"C:\Users\Brandon\source\repos\GetTargetPathRepro\GetTargetPathRepro.sln" (default target) (1:2) ->
"C:\Users\Brandon\source\repos\GetTargetPathRepro\ClassLibrary1\ClassLibrary1.csproj.metaproj" (default target) (4) ->
"C:\Users\Brandon\source\repos\GetTargetPathRepro\ClassLibrary1\ClassLibrary1.csproj" (default target) (2:6) ->
"C:\Users\Brandon\source\repos\GetTargetPathRepro\ClassLibrary1\ClassLibrary1.csproj" (_GetFrameworkAssemblyReferences target) (2:10) ->
"C:\Users\Brandon\source\repos\GetTargetPathRepro\ClassLibrary2\ClassLibrary2.csproj" (GetTargetPath target) (3:15) ->
  C:\Users\Brandon\source\repos\GetTargetPathRepro\ClassLibrary2\ClassLibrary2.csproj : error MSB4057: The target "GetTargetPath" does not exist in the project.

    0 Warning(s)
    1 Error(s)

Environment data

It repros with MSBuild 15.9.21.664 and 16.0.461.62831.
It also repros with .NET Core SDK 2.2.106 and 3.0.100-preview3-010431

I believe it worked fine before MSBuild 15.9, but I don't know an exact version.

[rainersigwald]

This is fairly involved. It's related to https://github.com/Microsoft/msbuild/commit/3258497c668ff3d0cd699975923b6cd593a1703d, which was in 15.8.

NuGet packaging calls _GetFrameworkAssemblyReferences which builds the current project (ClassLibrary1) with a specified TargetFramework and BuildProjectReferences = false. That is a distinct build from the "real" build of that project, so it creates a new project instance. That instance then tries to ResolveProjectReferences, which fails because when BuildProjectReferences != true, it calls GetTargetPath instead of the default target. That then fails, because GetTargetPath isn't defined for the outer build of a multitargeted project.

I think NuGet should special case the GeneratePackageOnBuild case for a single-targeted project to collapse to the current build, which already has references resolved.

This can be worked around by adding a Directory.Build.props for your solution with this property:

<Project>
 <PropertyGroup>
  <AddSyntheticProjectReferencesForSolutionDependencies>false</AddSyntheticProjectReferencesForSolutionDependencies>
 </PropertyGroup>
</Project>

[bording]

Since building from Visual Studio seems work fine and not result in an error, I assume that's because it has a different way of invoking all of this?

This can be worked around by adding a Directory.Build.props for your solution with this property:

The workaround I came up with that seems to be working was to switch to a ProjectReference with
ReferenceOutputAssembly="false" and PrivateAssets="All" set.

[bording]

I think NuGet should special case the GeneratePackageOnBuild case for a single-targeted project to collapse to the current build, which already has references resolved.

I could be misunderstanding what you're saying here, but the problem still occurs when ClassLibrary1 is multi-targeted a well.

[rainersigwald]

Since building from Visual Studio seems work fine and not result in an error, I assume that's because it has a different way of invoking all of this?

Yes, unfortunately. VS builds projects in a solution using a pretty different mechanism from MSBuild's solution handling.

The workaround I came up with that seems to be working was to switch to a ProjectReference with
ReferenceOutputAssembly="false" and PrivateAssets="All" set.

Yeah, if that works for you I'd prefer it over a solution dependency--it's clearer from the MSBuild side.

[sebashek]

FWIW, I had 2 references to the same project within the solution. Opening the csproj file with a text editor indicated that (Visual Studio did not, neither did a 'remove project reference' > 'add project reference').

The 2 references had different guids, 1 of them was the incorrect one.

[matiasdd]

I had the same error and somewhat similar to @sebashek, I had two identical project references listed in a single project file. Removing one of the references fixed the issue.

[bording]

@rainersigwald I see this still has no milestone. Any plans to address at some point?

[bizzbizz]

I had the same issue. When I modified a project and changed its assembly name, an NUnitTest project referencing the modified project couldn't build anymore. Other projects referencing the modified project wasn't affected.

I noticed that this error was purely because of a space in the middle of the new AssemblyName of the modified project. When I removed the space NUnit project started working again.

This bug is basically preventing me from having a space in name of any assembly which has a unit test.

workaround: rename assembly and remove spaces

[coderb]

i'm getting this error in visual studio 2019 using a solution with a mix of old-style and new style multi-targeted csproj files.

not sure where to go from here.

[jbennink]

Not sure if this is related But I came here for the error, whil inspecting my csporj I noticed I had somehow included the same projectreference twice! After removing the duplicate my error went away. So at least there are more reasons that you can get this error

[rokups]

This is very problematic for CMake projects that use include_external_msproject() to add manually crafted multi-target C# projects. Workaround does not work in this case.

[Ian1971]

I had the same double project reference in the csproj as others, removing that fixed it.