Dotnet pack injecting buildProperties into target project path

[mendoncaftw]

Question, Bug, or Feature?
Type: Bug

Enter Task Name: DotNetCoreCLI@2

Environment

• Server - Azure Pipelines

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: ticketline/Operations Management/_build?definitionId=22

• Agent - Hosted:

  • If using Hosted agent, provide agent queue name: Azure Pipelines

Issue Description

From yesterday to today, dotnet pack tasks have started to fail in all of my projects pipelines. On the logs the emphasis is mine. The task somehow is injecting the buildProperties PackageVersion into the pack target project path. This started happening today on all our projects that have the same steps, just changing the project name.

variables:
- name: Configuration
  value: Release

(...)

- task: DotNetCoreCLI@2
  displayName: dotnet pack
  inputs:
    command: 'pack'
    packagesToPack: './src/project_name/project_name.csproj'
    nobuild: true
    includesymbols: true
    versioningScheme: 'off'
    buildProperties: 'Configuration=$(Configuration);PackageVersion=$(NuGetVersion)'
    verbosityPack: 'Minimal'

Task logs

Starting: dotnet pack

Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.202.0
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli

/opt/hostedtoolcache/dotnet/dotnet pack /home/vsts/work/1/s/src/project_name/project_name.csproj --output /home/vsts/work/1/a --no-build --include-symbols /p:Configuration=Release;PackageVersion=0.12.24 --verbosity Minimal
MSBuild version 17.3.0+92e077650 for .NET
/opt/hostedtoolcache/dotnet/sdk/6.0.400/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(221,5): error NU5026: The file '/home/vsts/work/1/s/src/project_name/bin/Release;PackageVersion=0.12.24/net6.0/project_name.dll' to be packed was not found on disk. [/home/vsts/work/1/s/src/project_name/project_name.csproj]
##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
##[error]Error: The process '/opt/hostedtoolcache/dotnet/dotnet' failed with exit code 1
##[error]An error occurred while trying to pack the files.
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
Finishing: dotnet pack

[doug-allen-xerox]

Same issue

[raphael-dumhart]

Same for us. All of a sudden dotnet pack tasks fail in our pipelines. We're using the task pretty much the same as @mendoncaftw.

Comman according to logs:
C:\hostedtoolcache\windows\dotnet\dotnet.exe pack D:\a\1\s\ApiCommunication\ApiCommunication.csproj --output D:\a\1\a --no-build "/p:Configuration=Release;PackageVersion=1.0.109" --verbosity Detailed

Error message:
C:\hostedtoolcache\windows\dotnet\sdk\6.0.400\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(221,5): error NU5026: The file 'D:\a\1\s\ApiCommunication\bin\Release;PackageVersion=1.0.109\net6.0\RaccoonDynamics.Common.ApiCommunication.dll' to be packed was not found on disk. [D:\a\1\s\ApiCommunication\ApiCommunication.csproj]

[sandejd1]

Potentially related to dotnet/sdk#27059. I don't think I can use their suggested workaround because of the code on this line:

azure-pipelines-tasks/Tasks/DotNetCoreCLIV2/packcommand.ts

Line 166 in 7adc2fa

dotnet.arg("/p:" + properties.join(";"));

. This is what is relevant in my scenario but there is a good chance there are other places that would be impacted.

[shaunlavallee]

Same problem here.

Even with only one item in the buildProperties, the config property was injected in the path, thus giving an error saying it could not find the fil.

We had to downgrade and specify the sdk version 6.0.302, for the moment...

[X-Celcius]

This is a big issue for us as well. When specifying versions using buildProperties they get added to the configuration, leading to failed builds.

- task: DotNetCoreCLI@2
  inputs:
    command: pack
    configuration: $(buildConfiguration)
    packagesToPack: '**/*.csproj'
    buildProperties: 'InformationalVersion=0.0.0-dev+?.?'

We are passing other properties as well, I have shortened it to illustrate the issue.
This will try to run the following command:

dotnet.exe pack D:\Agents\[...].csproj --output [...] /p:Configuration=Release;InformationalVersion=0.0.0-dev+?.?

Starting with dotnet sdk 6.0.400 this will then pass the full string as the configuration string, leading to the following output path:

Property reassignment: $(OutputPath)="bin\Release;InformationalVersion=0.0.0-dev+?.?\net472\"

In our specific case this will fail because of the question marks in the path. In other cases it may pass but these properties should definitely not be part of the build configuration.

So is the dotnet sdk behaving more correct now and should the DotNetCoreCLI task be fixed or is this a regression in the dotnet sdk?

Sidenote:
When specifying 6.0.302 as a workaround in UseDotNet the DotNetCoreCLI task will happily continue using 6.0.400 if it's already cached. This is probably by design but it makes applying the downgrade workaround even more cumbersome.

[KungFuCookie]

Is there a temporary work around?
How do we force 6.0.302 ?

I fixed mine by removing/wiping Additional Build Properties (under Advanced) in the release pipeline - this value found it's way into the path to runtimeconfig.json, which cause my error

[X-Celcius]

Contrary to the documentation the UseDotNet task doesn't really enforce a certain version for subsequent dotnet commands. Instead they will always use the latest SDK installed (see this issue).

But you can use a global.json file as described here:
https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

[michaelbrianlake]

I just set the SDK version before i build or pack.

- task: UseDotNet@2
   inputs:
     packageType: 'sdk'
     version: '6.0.300'

[X-Celcius]

I just set the SDK version before i build or pack.

- task: UseDotNet@2
   inputs:
     packageType: 'sdk'
     version: '6.0.300'

If that works for you, fine, but this actually only downloads the SDK if it's not already cached. Running DotNetCoreCLI afterwards will still always select the newest SDK from the cache by default. So if you ever downloaded something newer (e.g. 6.0.400) UseDotNet won't help you. But we're going slightly off topic here, this has been discussed elsewhere already and seems to be intended behavior.

[X-Celcius]

I just noticed the issue in the dotnet sdk (dotnet/sdk#27059) has actually already been resolved in this PR: dotnet/sdk#27086.
So I expect this issue here to be resolved as well once dotnet sdk 6.0.401 is released.

[seangwright]

Not sure if 6.0.401 is on the windows hosted agents yet, but the docs still say 6.0.400.

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days