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

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.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 6
Comments: 21 (5 by maintainers)

Commits related to this issue

work around https://github.com/dotnet/msbuild/issues/4303 — committed to Fody/Fody by SimonCropp 3 years ago
work around https://github.com/dotnet/msbuild/issues/4303 — committed to tom-englert/SplashScreen.Fody by tom-englert 3 years ago
Fix for MSB4057: The target GetTargetPath does not exist in the project. See: https://github.com/dotnet/msbuild/issues/4303#issuecomment-482345617. — committed to NightOwl888/ICU4N by NightOwl888 2 years ago
Fix for MSB4057: The target GetTargetPath does not exist in the project. See: https://github.com/dotnet/msbuild/issues/4303#issuecomment-482345617. — committed to NightOwl888/ICU4N by NightOwl888 2 years ago
Try fix from https://github.com/dotnet/msbuild/issues/4303#issuecomment-1271875232 — committed to CommunityToolkit/Tooling-Windows-Submodule by michael-hawker a year ago

Most upvoted comments

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.

+20

matiasdd on Nov 26, 2019

After long struggles with the problem using include_external_msproject() I finally found an applicable workaround on https://github.com/wixtoolset/issues/issues/5705:

  <Target Name="GetTargetPath" Returns="@(_FakeOutputPath)">
    <ItemGroup>
      <_FakeOutputPath Include="$(MSBuildProjectDirectory)\$(PackageOutputPath)\$(AssemblyName).dll" />
    </ItemGroup>
  </Target>

NorbertNemec on Aug 11, 2021

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

jbennink on Dec 7, 2020

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>

rainersigwald on Apr 11, 2019

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.

coderb on Sep 18, 2020

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

bording on Mar 10, 2020

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.

sebashek on Sep 30, 2019

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

This was the fix for me, using xUnit. My Test assembly was referencing several projects, and the problems were only with the ones that had spaces in them, but I never would have thought that this sort of thing would still cause problems in 2022.

TheRealAyCe on May 3, 2022

This also happened to me with 17.0.1, I have created a bug report here: https://developercommunity.visualstudio.com/t/Multi-framework-C-project-fails-build-w/1590856?space=8&q=guhidalg&entry=problem

ghidalgo3 on Nov 23, 2021

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

bizzbizz on Mar 26, 2021