Issue running dotnet publish with --output property set

[vukvucic]

Description

Our pipeline on Azure running the DotNetCoreCLI@2 - .NET Core v2 task no longer seems to work because of the --output property set.

This property is still outlined in the Microsoft documentation for the dotnet publish command https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish but we can no longer use it.

Configuration

.NET version: 7.0.*

Previous working version
MSBuild version 17.4.1+9a89d02ff for .NET

Current version
MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET

At the moment we haven't found a way to limit the MSBuild version so we are unable to go back to the working version.

Error message

MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET
D:\Agent_Dps2\_work\_tool\dotnet\sdk\7.0.200\Current\SolutionFile\ImportAfter\Microsoft.NET.Sdk.Solution.targets(36,5): error NETSDK1194: The "--output" option isn't supported when building a solution. [D:\Agent_Dps2\_work\32\s\Project.sln]
##[error]Error: The process 'D:\Agent_Dps2\_work\_tool\dotnet\dotnet.exe' failed with exit code 1

Other information

There seems to have been a bug about this in a previous version that was fixed but it may have regressed: dotnet/runtime#79330.

[mairaw]

@baronfel can you help with this one?

[baronfel]

Yes, this is intended and was implemented in dotnet/sdk#29065, but we haven't written the breaking change documentation for that. I'll make sure that happens tomorrow.

Publish at the solution level isn't well defined because the project can and do overwrite each other. This has led to a number of issues from internal and external users around ordering.

The workaround for users that did do this is to publish each relevant project individually, where the output path has clear semantics.

[chkoella]

We have the same issue. We have a pipeline that is suddenly failing. The difference is that it used the dotnet SDK 6.0.405 on the last successful build and with SDK 6.0.406 it fails. As this is a revision update I don't expect a behavior change that produces an error. I would be OK with a warning but not with an error.
I also think that a preview MSBuild version (MSBuild version 17.5.0-preview-23061-01+040e2a90e for .NET) should not be in a non preview SDK.

[aliuspetraska]

@baronfel just a comment from my side that now all pipelines built automatically by Azure Web Apps is failing. So Azure Portal can't create the right yml as well. So the problem is on SDK ground breaking changes and Azure Portal.

[MCKanpolat]

dotnet pack command also affected with this change.

dotnet pack xyz.sln --no-build --no-restore --output /xyz -p:PackageVersion=1.0.10 --configuration Release

In the previous version it was possible to pack the projects of the solution into a folder.

Also its valid syntax according to the cli documentation.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-pack

[baronfel]

I've added a breaking change notice for this change here, as well as updated the docs for the associated commands - I'll work with the docs team to get it merged ASAP today.

[baronfel]

Some follow up for those hitting this issue:

We've been discussing the introduction of the new error and will be taking the following actions based on everyone's feedback in this (and other!) threads - THANK YOU for making your feedback known, please keep it up in the future.

a) We'll downgrade the error to a warning - we think this usage pattern is harmful and can lead to builds that are harder to debug, especially when projects are multi-targeted or have differing sets of PackageReference versions.
b) We'll skip the logic for the pack command entirely - pack has stable and correct semantics when the -o flag is specified (because it sets PackageOutputPath instead of OutputPath directly)

We will put this up for inclusion into next month's servicing release of the .NET SDK, which is the soonest possible ship vehicle we have for this kind of change. In the meantime, you can restore the previous behavior by changing the use of -o to a specific property. If you want to maintain the existing behavior exactly, then you can use the --property flag to set a MSBuild property to the desired directory. The property to use varies based on the command:

Command	Property	Example
build	OutputPath	dotnet build --property OutputPath=DESIRED_PATH
clean	OutputPath	dotnet clean --property OutputPath=DESIRED_PATH
pack	PackageOutputPath	dotnet pack --property PackageOutputPath=DESIRED_PATH
publish	PublishDir	dotnet publish --property PublishDir=DESIRED_PATH
store	OutputPath	dotnet store --property OutputPath=DESIRED_PATH
test	TestResultsDirectory	dotnet test --property OutputPath=DESIRED_PATH

[Infionion]

For pipelines, specifying the projects to publish seems to still be working with the output argument.
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/dotnet-core-cli-v2?view=azure-pipelines#inputs
- task: DotNetCoreCLI@2
displayName: dotnet publish
inputs:
command: "publish"
publishWebProjects: false
projects: "$(projects)"
modifyOutputPath: false
arguments: "--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)"

[tsutomi]

I have encountered the same issue and it broke my pipelines in GitHub, for packing and publishing.

Following the advices to the related issue #30624 I have made the following changes:

dotnet pack [...] --property PackageOutputPath=${GITHUB_WORKSPACE}/nuget
dotnet nuget push ./nuget/**/*.nupkg [...]

Such an unfortunate situation, that affected a lot of the pipelines, since I am publishing a lot of packages internally (client libraries to microservices)

[Pentadome]

Why does a minor version change have a breaking change?

[baronfel]

@Pentadome the SDK doesn't have a SemVer contract - the final number (100, 101, 103) is called the 'feature band' and within that feature band things are generally expected to remain 100% compatible. Between feature bands we do introduce new features, warnings, analyzers, etc - this is how this change was introduced. We do try to limit the number of breaking changes, saving them for major versions, but when making this change we drastically under-counted the expected users that were using this mode. In next month's patch release of the 7.0.2xx feature band this will be downgraded to a warning only (because it is a problem from a build consistency/correctness perspective, and we have had many user-reported issues about it), which is what it should have been overall.

You can read more about SDK versioning here.

[MiroslawSlanda]

The task DotNetCoreCLI@2 is also not working because it depends on which version of MSBuild you have on your agent who works on the pipeline.

[MiroslawSlanda]

If someone needs to fix that issue now, then:

1. He needs to change a version of SDK from 7.0.x to 7.0.3:

- task: UseDotNet@2
    displayName: 'Use .NET SDK 7.0.103'
    inputs:
      packageType: 'sdk'
      version: '7.0.103'

2. Then he must remove the dotnet from an agent which is used to build a pipeline. Renaming the folder dotnet is enough.
3. In the end he need only run the pipeline.

[nino-s]

@MiroslawSlanda I customized the installation path, so you don't need to remove dotnet from an agent.

- task: UseDotNet@2
  displayName: 'Configure .NET Core SDK version'
  inputs:
    installationPath: '$(Agent.TempDirectory)/dotnet7.0.103'
    packageType: 'sdk'
    version: '7.0.103'

[marcpopMSFT]

dotnet/sdk#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.

[babakjafari4]

This line code needs to be changed as follows:

• name: dotnet publish
  run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

to:

• name: dotnet publish
  run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp -f=net7.0

In order to publish an app using .net core, it seems we must set the target framework explicitly.

[luebster]

This is what my old dotnet publish command looked like (.NET Core web app, 1 solution file, 1 project file)

run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

This is what it looks like now (zero warnings or errors)

run: dotnet publish -c Release -property:PublishDir=${{env.DOTNET_ROOT}}/myapp

[mfalconi-perle]

This line code needs to be changed as follows:

• name: dotnet publish
  run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

to:

• name: dotnet publish
  run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp -f=net7.0

In order to publish an app using .net core, it seems we must set the target framework explicitly.

Is this a new change? I had a workflow that was working fine that broke without a change added in the last few days