Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building a VS solution file at the command line now causes MSB4057 #6373

Closed
snalexp opened this issue Apr 26, 2021 · 23 comments · Fixed by #6465
Closed

Building a VS solution file at the command line now causes MSB4057 #6373

snalexp opened this issue Apr 26, 2021 · 23 comments · Fixed by #6465

Comments

@snalexp
Copy link

snalexp commented Apr 26, 2021

Issue Description

I have a solution file with several projects in and use -targets to selectively build some projects in this solution.

Using

msbuild --version
Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.9.0.16703

The following works:

msbuild -p:Platform=x64 -p:Configuration=Debug -t:banana SolutionFile.sln

but since installing VS 2019 16.10 Preview 2.1, I now receive error MSB4057: The target "banana" does not exist in the project. for every project in the solution.

I think this update to Visual Studio brought this version of MSBuild with it:

msbuild --version
Microsoft (R) Build Engine version 16.10.0-preview-21181-05+80f316e90 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.10.0.18105

Steps to Reproduce

I have been unable to reproduce this issue in a new project. Unfortunately I cannot share the entire solution with you, nor is it open source.

Expected Behavior

The specified project is targeted and built from the solution.

Actual Behavior

The build does not complete.

Analysis

I emitted the metaproj for build instances, and it looks like there are a few differences, but this one looks related. Looking at SolutionFile.slnmetaproj, I have these two blocks:

16.9

  <Target Name="banana" Outputs="@(bananaBuildOutput)">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="bananaBuildOutput" />
    </MSBuild>
  </Target>
  <Target Name="banana:Clean">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Clean" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" />
  </Target>
  <Target Name="banana:Rebuild" Outputs="@(bananaBuildOutput)">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Rebuild" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="bananaBuildOutput" />
    </MSBuild>
  </Target>
  <Target Name="banana:Publish">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Publish" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" />
  </Target>

16.10

  <Target Name="banana">
    <MSBuild BuildInParallel="True" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)" Projects="@(ProjectReference)" Targets="banana" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionFilterName=$(SolutionFilterName); SolutionPath=$(SolutionPath)" />
  </Target>
  <Target Name="banana:Clean">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Clean" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionFilterName=$(SolutionFilterName); SolutionPath=$(SolutionPath)" />
  </Target>
  <Target Name="banana:Rebuild" Outputs="@(bananaBuildOutput)">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Rebuild" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionFilterName=$(SolutionFilterName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="bananaBuildOutput" />
    </MSBuild>
  </Target>
  <Target Name="banana:Publish">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="Publish" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionFilterName=$(SolutionFilterName); SolutionPath=$(SolutionPath)" />
  </Target>
  <Target Name="banana:banana">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\code\banana\msvc\2019\banana.vcxproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Targets="banana" Properties="Configuration=Debug; Platform=x64;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionFilterName=$(SolutionFilterName); SolutionPath=$(SolutionPath)" />
  </Target>

After inspecting these generated targets, I can confirm that -t:banana:Clean works in both cases i.e.

msbuild -p:Platform=x64 -p:Configuration=Debug -t:banana:Clean SolutionFile.sln

As does -t:banana:Rebuild.

So I tried -t:banana:banana and this was somewhat of an improvement. It found the correct vcxproj target from the solution but then generated the same error as earlier:

C:\code\banana\msvc\2019\banana.vcxproj : error MSB4057: The target "banana" does not exist in the project.

The main difference between -t:banana and -t:banana:banana is that the former causes MSB4057 for every project in the solution, whereas the latter seems to find the correct project, but then banana does not exist as a target within that project (which makes sense to me).

Versions & Configurations

Working:

msbuild --version
Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.9.0.16703

Not working:

msbuild --version
Microsoft (R) Build Engine version 16.10.0-preview-21181-05+80f316e90 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.10.0.18105

OS is Windows 10, x64, 20H2 (19042.928)

Attach a binlog

Not available.

Thank you!

@snalexp snalexp added bug needs-triage Have yet to determine what bucket this goes in. labels Apr 26, 2021
@benvillalobos
Copy link
Member

Team Triage: Would it be possible for you to share your .sln file without any of the projects? If you're not comfortable posting it publicly would you be willing to file a Visual Studio Feedback Ticket and upload it privately?

@snalexp
Copy link
Author

snalexp commented Apr 28, 2021

Hi @benvillalobos,

I've attached one of our solutions with some anonymised names.

SolutionFile.zip

Hope that helps,

@snalexp
Copy link
Author

snalexp commented May 12, 2021

Hi,

This issue persists with the recent VS preview update:

msbuild --version
Microsoft (R) Build Engine version 16.10.0-preview-21253-02+fa96a2a81 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.10.0.25302

@warappa
Copy link

warappa commented May 12, 2021

Same problem when using tye - but building in Visual Studio and through dotnet build was all fine!

My error message was The target "Restore" does not exist in the project.

I had VS 2019 16.9.5 and VS 2019 16.10.0 Preview 3.0 installed. Tried reinstalling the ".NET Portable Library Targeting Pack" as suggested in an old issue at Newtonsoft:Json (JamesNK/Newtonsoft.Json#2057). Did not work.

Solution: Uninstall VS 2019 16.10.0 Preview 3.0

I had just today updated the preview and stable version of VS. So I completely uninstalled VS 2019 16.10.0 Preview 3.0 and that fixed the issue immediately, so it is definitely something in the latest preview update.
Note: VS 2019 16.10.0 Preview 2.1 did not cause any issues: tye run worked flawlessly.

@Forgind
Copy link
Member

Forgind commented May 14, 2021

@benvillalobos,
#6312 didn't only fail with Restore; that was just the common scenario. Could this just be a different manifestation of that?

and use -targets to selectively build some projects in this solution.

Could this be better done with a solution filter?

@benvillalobos
Copy link
Member

@warappa A fix for that tye issue will be fixed in 16.10 P4.

@warappa
Copy link

warappa commented May 19, 2021

@benvillalobos I just tested it. Unfortunately installing 16.10 Pre4 causes the same error. Just minutes earlier without 16.10 Pre 4 it worked, so it is definitely the update again.

I'm not the only one with this issue:
dotnet/tye#1003 (comment)
dotnet/tye#1024 (comment)

@rainersigwald
Copy link
Member

@warappa ah, what's happening is that VS 16.10 preview 4 delivers a .NET SDK that has an MSBuild that doesn't have the fix. When the next .NET SDK preview releases with a fixed MSBuild, tye should work fine again.

@grantborthwick
Copy link

I'm seeing this on the release of 16.10.0 - I have a sln that I can share internally.

@Forgind
Copy link
Member

Forgind commented May 26, 2021

@grantborthwick, the solution for this has been merged and should go into 16.10.1. Let me know if you need it early or if it doesn't work!

@Forgind Forgind closed this as completed May 26, 2021
@jerharmon
Copy link

Glad this has been resolved, do you know when 16.10.1 will be released?

@Forgind
Copy link
Member

Forgind commented May 26, 2021

Probably 1-3 weeks from now.

@michalproks
Copy link

Hi, we are also encountering this issue. We tried solving it by custom build from the vs16.10 branch, which resolved most of the issues, however we probably went wrong somewhere because now when we build the project from Visual Studio first and then trying to build the same project from msbuild (without clean inbetween) we get the following warnings:

warning C4599: '/IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\include': command line argument number 3 does not match precompiled header

Would it be possible to do some hotfix release, or just a separate msbuild release that would work with VS 16.10.0? Thanks

@rainersigwald
Copy link
Member

@michalproks We got it into the first possible hotfix release, but we'll have to wait for the wheels to turn on the release process there.

I'd be very surprised if the C4599 warning you're seeing is related to you patching MSBuild though. That sounds like the build configuration is subtly different in VS versus MSBuild.exe.

@rainersigwald
Copy link
Member

A workaround from Stack Overflow user chrsdy is to specify the :Rebuild target for the projects explicitly.

msbuild.exe MySolution.sln /t:Project1:Rebuild;Project2:Rebuild;Project3:Rebuild /p:Configuration=Release /p:DebugType=None /p:OutputPath="C:\Users\myuser\Desktop\Build"

@rhuijben
Copy link

Can't wait to get a fix. Breaks my entire buildchain scripting.

@Appelg
Copy link

Appelg commented May 31, 2021

Why did you release/upgrade this version on azure pipelines? Our builds started failing. How can I specify an older version in Azure / VsBuild-task?

Edit:
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/visual-studio-build?view=azure-devops
vsVersion parameter. Great. Lets enter 16.9 there, makes sense.
##[warning]Visual Studio version '16.9' not found. Falling back to version '16.0'.

.... really nice. Who decided that the only valid options are xx.0 and that automagically gets me the latest version?

https://github.com/actions/virtual-environments/pull/3452/files
I just want to revert to using the build-image BEFORE this one, but that doesn't seem like it's possible?
I.e, I thought that entering for example 16.9 as vsVersion in the vsbuild-task would give me the "virtual-environments"-image with just that version, but it seems like theres only once choice, and that is to always use the latest version.....

@lelegard
Copy link

Why did you release/upgrade this version on azure pipelines?

Same on GitHub Actions, all test workflows were broken, needed to update all build scripts to implement the :Rebuild workaround.

targos added a commit to targos/node that referenced this issue May 31, 2021
aduh95 pushed a commit to targos/node that referenced this issue May 31, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: nodejs#38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: nodejs#38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
danielleadams pushed a commit to nodejs/node that referenced this issue Jun 1, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: #38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: #38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
@benvillalobos benvillalobos pinned this issue Jun 2, 2021
@jespergustinmsft
Copy link

Is there any chance a regression test for this has/can be implemented? Seems like a very basic functionality that should not be allowed to be broken by a PR?

@Forgind
Copy link
Member

Forgind commented Jun 3, 2021

Indeed! This is my test.

targos added a commit to nodejs/node that referenced this issue Jun 5, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: #38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: #38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
targos added a commit to nodejs/node that referenced this issue Jun 5, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: #38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: #38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
targos added a commit to nodejs/node that referenced this issue Jun 5, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: #38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: #38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
@rainersigwald
Copy link
Member

VS 16.10.1 is now released.

@grantborthwick
Copy link

I can confirm that VS 16.10.1 fixes this issue for my build. Thanks!

@snalexp
Copy link
Author

snalexp commented Jun 10, 2021

I can confirm that VS 16.10.1 fixes this issue for my build. Thanks!

Same here - thank you.

targos added a commit to nodejs/node that referenced this issue Jun 11, 2021
This allows to build Node.js at the (temporary) cost of longer build
times.

Refs: #38872
Refs: https://github.com/dotnet/msbuild/releases/tag/v16.10.0
Refs: dotnet/msbuild#6465
Refs: dotnet/msbuild#6373

PR-URL: #38873
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Antoine du Hamel <[email protected]>
Reviewed-By: Gerhard Stöbich <[email protected]>
BrunoC-L added a commit to BrunoC-L/sfml-rs2d that referenced this issue Jun 12, 2021
…e problem that somehow is affecting most likely everyone using external runners that upgraded to 16.10 dotnet/msbuild#6373 (comment)
@rainersigwald rainersigwald unpinned this issue Jun 15, 2021
hn-88 added a commit to hn-88/pan2fulldome that referenced this issue Jul 15, 2023
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.