Error msb4057 the target gettargetpath does not exist in the project

"C:UsersBrandonsourcereposGetTargetPathReproGetTargetPathRepro.sln" (default target) (1:2) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj.metaproj" (default target) (4) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj" (default target) (2:6) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary1ClassLibrary1.csproj" (_GetFrameworkAssemblyReferences target) (2:10) ->
"C:UsersBrandonsourcereposGetTargetPathReproClassLibrary2ClassLibrary2.csproj" (GetTargetPath target) (3:15) ->
  C:UsersBrandonsourcereposGetTargetPathReproClassLibrary2ClassLibrary2.csproj : error MSB4057: The target "GetTargetPath" does not exist in the project.

    0 Warning(s)
    1 Error(s)

This is fairly involved. It’s related to 3258497, 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>

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

@rokups — did you find a solution for the problem with include_external_msproject()? I seem to be stumbling over the same issue.

I do not remember. I am not dealing with this issue any more, but i can not find any relevant commits from the time of my post. Not sure if this happened in some experimental branch that i later scrapped… Sorry for being useless

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

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

I seemed to get this after changing TargetFramework —> TargetFrameworks. The project I did this in started failing to build, but only in builds with other projects that depended on it (worked when I built it by itself). In the end I only needed one target framework so dropped the s again and that seemed to force VS to re-evaluate something that no amount of cleaning/rebuilding or opening/closing VS could solve. 🤷🏻‍♂️

I added a comment to your report @ghidalgo3. It’s too complicated to create a simple repro though.

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.

For me this issue got introduced when I started setting TargetPlatformMinVersion in the UWP project, because I wanted a smaller min-version but wanted to use the newer SDK. Only happens to the project referencing the multi-targeted project (which have the same min/max versions for UWP).

Found a workaround for UWP case: In the second project pluralize TFM so it says TargetFrameworks and problem goes away 🤦