search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.24k stars 1.35k forks source link

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

Open bording opened 5 years ago

bording commented 5 years ago

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;

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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

bizzbizz commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

NorbertNemec commented 3 years ago

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

rokups commented 3 years ago

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 commented 3 years ago

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>
benmccallum commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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

TheRealAyCe commented 2 years ago

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 commented 2 years ago

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

dotMorten commented 2 years ago

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

cheesi commented 2 weeks ago

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.