Build fails when using sdk version 7.0.200

[GregorLamche]

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

[KalleOlaviNiemitalo]

The NETSDK1194 error was intentionally added in #29065, to fix #15607.

It hasn't yet been documented at .NET SDK error list, though. Perhaps it should be added to Breaking changes in .NET 7, too.

[GregorLamche]

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.

[GregorLamche]

Updated description with building project workaround.
This however breaks testing in turn and is not an acceptable solution, unless cascading workarounds.

[KalleOlaviNiemitalo]

Can you use .NET SDK 7.0.103 for now? It does not include this change.

[GregorLamche]

Yes, updated issues with package downgrade workaround.

[KalleOlaviNiemitalo]

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.

[xavierjohn]

.NET SDK 7.0.103 works for me but 7.0.200 fails.
https://github.com/xavierjohn/FunctionalDDD/actions/runs/4179702217/jobs/7240030706

[buvinghausen]

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

[baronfel]

There's a follow up on this situation here.

[Matthewsre]

This just broke a few of my GitHub Actions using dotnet pack

dotnet pack src/Service.Extensions.Public.slnf -p:PackageVersion=$VERSION -c Release --output nupkgs

Still should be working according to the docs:

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-pack

Then stumbled across this issue :(

[Shane32]

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 to dotnet pack when it should not be. Note that the --output option for dotnet pack does not affect the solution build target directory even if --no-build was 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

[altso]

FYI, --output could replaced with -p:PackageOutputPath={path} in dotnet pack command.

[Shane32]

I will attempt to use the dotnet pack --property:PackageOutputPath=DESIRED_PATH solution before downgrading as listed in #30624 (comment) . 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!!!

[baronfel]

@Shane32 agree on all counts. A few notes:

• docs PRs have been made and are awaiting merge
• the fixed version (which has been merged and will release next month) will not apply to pack at all, exactly for the reasons you give

[buvinghausen]

I just put the following line in Directory.Build.props for my nuget solution and it works just fine

<PackageOutputPath>..\..\</PackageOutputPath>

From there you can wildcard push...

dotnet nuget push "*.nupkg"

Note: this hoists the packages up from the \src\{Project} folder to the solution root. Obviously your folder structure may vary.

[renemadsen]

• the fixed version (which has been merged and will release next month) will not apply to pack at all, exactly for the reasons you give

When in next month?

We have a lot of nuget packages, where the CI/CD is broken now due to this issue, so would be nice to know if we should spend time change all processes to use the --property:PackageOutputPath instead of --output or we can live with waiting for it to be released.

[marcpopMSFT]

#30624 (comment)

[Den4ikzxcv]

We faced the same problem with dotnet pack.
We fixed it by searching for needed .csproj file:

was before:
dotnet pack --configuration Release /p:Version=${VERSION} --no-build --output .
now:
dotnet pack **/Your.Project.csproj --configuration Release /p:Version=${VERSION} --no-build --output .

[sungam3r]

Agree with #30625 (comment) . We intentionally use --no-build and --no-restore in the pack command.

the fixed version (which has been merged and will release next month) will not apply to pack at all, exactly for the reasons you give

@baronfel 👍

[EvilVir]

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.

[spiko-md]

because some random guys had overwritten their files with it?

There seems to be some other reasoning behind it, but I agree, IMO this is a breaking change and should go to a major version.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/7.0/solution-level-output-no-longer-valid

[EvilVir]

There seems to be some other reasoning behind it

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.

[baronfel]

@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 #30624 (comment).

[baronfel]

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 --output parameter mentioned above: it is downgraded to a warning, and the check no longer applies to the pack command.

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.

[Shane32]

Thanks! So far GitHub Actions' actions/setup-dotnet with 7.0.x still won't pull 7.0.201 unfortunately -- at least, not for me.

• Requesting 7.0.x does not install 7.0.201 actions/setup-dotnet#388

[EvilVir]

All got back to normal on my end. Thank you!

[stunney]

This issue is ALSO happening for 6.0.* builds:
dotnet/core#8245

[Shane32]

Last night, 7.0.201 was released through all the various channels.

All URLs for 7.0 were not properly updated - see here:

• Using -Channel 7.0 option leads to wrong .NET SDK version installed install-scripts#357