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 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>

[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.

[NorbertNemec]

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

[rokups]

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 :|

[NorbertNemec]

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>

[benmccallum]

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. 🤷🏻‍♂️

[ghidalgo3]

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

[kwaazaar]

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

[TheRealAyCe]

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.

[dotMorten]

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).

[dotMorten]

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

[cheesi]

I just had the same issue with the same conditions as described above:

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.

Only solution that worked for me was changing TargetFramework to TargetFrameworks as suggested by @dotMorten for the referencing project. No UWP involved in my case.