-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
Team Triage: Would it be possible for you to share your |
Hi @benvillalobos, I've attached one of our solutions with some anonymised names. Hope that helps, |
Hi, This issue persists with the recent VS preview update:
|
Same problem when using tye - but building in Visual Studio and through My error message was 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.0I 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. |
@benvillalobos,
Could this be better done with a solution filter? |
@warappa A fix for that tye issue will be fixed in 16.10 P4. |
@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: |
@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. |
I'm seeing this on the release of 16.10.0 - I have a sln that I can share internally. |
@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! |
Glad this has been resolved, do you know when 16.10.1 will be released? |
Probably 1-3 weeks from now. |
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:
Would it be possible to do some hotfix release, or just a separate msbuild release that would work with VS 16.10.0? Thanks |
@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 |
A workaround from Stack Overflow user
|
Can't wait to get a fix. Breaks my entire buildchain scripting. |
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: .... 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 |
Same on GitHub Actions, all test workflows were broken, needed to update all build scripts to implement the |
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
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]>
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]>
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? |
Indeed! This is my test. |
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]>
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]>
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]>
VS 16.10.1 is now released. |
I can confirm that VS 16.10.1 fixes this issue for my build. Thanks! |
Same here - thank you. |
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]>
…e problem that somehow is affecting most likely everyone using external runners that upgraded to 16.10 dotnet/msbuild#6373 (comment)
Issue Description
I have a solution file with several projects in and use
-targets
to selectively build some projects in this solution.Using
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:
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
16.10
After inspecting these generated targets, I can confirm that
-t:banana:Clean
works in both cases i.e.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: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 thenbanana
does not exist as a target within that project (which makes sense to me).Versions & Configurations
Working:
Not working:
OS is Windows 10, x64, 20H2 (19042.928)
Attach a binlog
Not available.
Thank you!
The text was updated successfully, but these errors were encountered: