sdk: Build fails when using sdk version 7.0.200
Describe the bug
Project fails to build when the sdk version 7.0.200 is used:
error NETSDK1194: The "--output" option isn't supported when building a solution.
Works fine with version 7.0.102 however.
To Reproduce
apt-get update
apt-get install -y --no-install-recommends dotnet-sdk-7.0 //<-- may or may not actually install version 7.0.200 depending on used source repos, Azure Pipeline pulls 200
dotnet restore "service.sln"
dotnet build "service.sln" -c Release -o /app/build --no-restore
We may close this issue if:
- the repro project you share with us is complex. We can’t investigate custom projects, so don’t point us to such, please.
- if we will not be able to repro the behavior you’re reporting –>
Exceptions (if any)
error NETSDK1194: The "--output" option isn't supported when building a solution.
Workaround
Downgrade to previous package:
apt-get install -y dotnet-sdk-7.0=7.0.103-1
This however breaks testing, and is not a solution.
Further technical details
- ASP.Net service
- Ubuntu Docker base image
- fails in Azure Pipeline
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 18
- Comments: 28 (5 by maintainers)
Commits related to this issue
- Disable v5 actions and force .NET 7.0.103 over 7.0.200 due to https://github.com/dotnet/sdk/issues/30625 — committed to DSharpPlus/DSharpPlus by OoLunar a year ago
- Temporary workaround for a bug, setting dotnet version to 7.0.103 for Mac job https://github.com/dotnet/sdk/issues/30625 — committed to JaredCuster/SCALUS by JaredCuster a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 — committed to npgsql/npgsql by vonzshik a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change (#4938) https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 — committed to npgsql/npgsql by vonzshik a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 — committed to npgsql/efcore.pg by vonzshik a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change (#2658) https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 — committed to npgsql/efcore.pg by vonzshik a year ago
- try fixing bug with https://github.com/dotnet/sdk/issues/30625 — committed to claasd/caffoa.net by claasd a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change (#2658) https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 (cherry picked from commit 6fafb37716f50575c22f... — committed to npgsql/efcore.pg by vonzshik a year ago
- Replace --output with --property for pack in ci to fix 7.0.2 breaking change (#4938) https://github.com/dotnet/sdk/issues/30625#issuecomment-1433569096 (cherry picked from commit 09fa2a218d9ccc467d47... — committed to npgsql/npgsql by vonzshik a year ago
- Update CI — committed to AlienDwarf/open-meteo-dotnet by AlienDwarf a year ago
- Disable v5 actions and force .NET 7.0.103 over 7.0.200 due to https://github.com/dotnet/sdk/issues/30625 — committed to Plerx2493/DSharpPlus by OoLunar a year ago
Do I understand correctly that you removed the very useful and important feature, that allowed flexibility, because some random guys had overwritten their files with it? And you did that in stable, production ready release?
Are you serious? What’s wrong with defining the output path? Those for whom solution wide output doesn’t work should reach for workarounds (like building each project separately and into different folder or not using —output flag), not everyone else!
There are tools and pipelines built around this flag, this is well known and expected behavior. If someone blames own misconfiguration on optional flag, then flag alone is least of their problems.
Please bring back original functionality.
Just bizarro land that you would merge in a breaking change for something that has literally worked without issue for almost 6 years at this point…
Based on #15607, NETSDK1194 was added to prevent building multiple solutions into a single folder. In my case, there is a bug and regression here, because I am not building to a single folder - in fact my CI script explicitly says
--no-build. However, the error is being applied todotnet packwhen it should not be. Note that the--outputoption fordotnet packdoes not affect the solution build target directory even if--no-buildwas not specified. I require all solutions to be packed into a single folder so that I can upload them all to NuGet in a single step. I’m sure this is common for anyone that is packing multiple projects together for NuGet, as it is the only logical way to construct the CI script. Please make a patch available asap. Until then I will need to stay on 7.0.103.cc: @sungam3r
I was under the impression that 7.0 was already out of the preview phase. Yes, this is a breaking change, and needs to be listed.
@EvilVir you’re entirely correct, we should not have introduced the change at this severity in this version. Please bear with us, as we’re in the process of releasing the 7.0.201 hotfix, as mentioned in https://github.com/dotnet/sdk/issues/30624#issuecomment-1435408741.
Reasoning is that „behavior is inconsistent”. Yeah, maybe it is but it’s well known fact, been there forever and that „inconsistency” was tamed by many and incorporated into the tools.
Just look at this topic - I bet my comment alone got more likes than there were people for whom that „inconsistency” was a problem and not desired behavior.
So it’s solution for few that became now new issue for many. Another good design choice .NET team! Whooohooo!
Anyway thank you for linking that article. After all that blablabla justifying this stupid change there’s at least list of options provided, that we all now can try to use to bring our tools back to life.
https://github.com/dotnet/sdk/issues/30624#issuecomment-1435408741
@Shane32 agree on all counts. A few notes:
I will attempt to use the
dotnet pack --property:PackageOutputPath=DESIRED_PATHsolution before downgrading as listed in https://github.com/dotnet/sdk/issues/30624#issuecomment-1432118204 . The documentation listed there MUST be included in the official documentation if there is to be a change. Currently, and I quote, it says “Places the built packages in the directory specified.”. Note specifically that “packages” is plural. There is nothing to indicate that a solution cannot be built.Having the functionality to place all built packages in a single folder is a necessity!!!
Hello folks, wanted to give you all an update on the situation.
Last night, 7.0.201 was released through all the various channels. It should already be available on GitHub Actions and AzDO runners, and of course for local installation. This hotfix contained the changes to the
--outputparameter mentioned above: it is downgraded to a warning, and the check no longer applies to thepackcommand.The other problem logged in this issue, MSBuild logging a prerelease version string, will be handled in the normal servicing schedule - likely with next month’s expected release of 7.0.202.
Thank you all for the feedback and discussion on this issue.
FYI,
--outputcould replaced with-p:PackageOutputPath={path}indotnet packcommand..NET SDK 7.0.103 works for me but 7.0.200 fails. https://github.com/xavierjohn/FunctionalDDD/actions/runs/4179702217/jobs/7240030706
I mean, both .NET SDK 7.0.103 and 7.0.200 include the fix for CVE-2023-21808 – .NET Remote Code Execution Vulnerability, so 7.0.103 would be safer than 7.0.102.