[REGRESSION]: DotNetCoreCLIV2 fails when zipAfterPublish is true

[jamesrock-asinpa]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

DotNetCoreCLIV2

Breaking task version

2.266.0

Last working task version

2.264.1

Regression Description

Using DotNetCoreCLI@2 successfully and without issue for more than 1 year. Yesterday build started failing with error:

Error: Failed rmRF: EPERM: operation not permitted, unlink 'D:\a\1\a(ApplicationFolder)'

Fixed issue by disabling the zipAfterPublish option; however this has increased the size of our deployment by almost 2X, which also almost doubled the deployment time. I see that the 7zip version was recently incremented; assume it's related?

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

windows-latest

Relevant log output

##[debug]Zip Source: D:\a\1\a\(MyApplicationFolder)
##[debug]Zip arguments: Source: D:\a\1\a\(MyApplicationFolder) , target: D:\a\1\a\(MyApplicationFolder).zip
##[debug]Agent environment resources - Disk: D:\ Available 7548.73 MB out of 14334.00 MB, Memory: Used 3475.00 MB out of 7167.00 MB, CPU: Usage 65.00%
##[debug]Agent environment resources - Disk: D:\ Available 7483.92 MB out of 14334.00 MB, Memory: Used 3459.00 MB out of 7167.00 MB, CPU: Usage 100.00%
##[debug]Agent environment resources - Disk: D:\ Available 7416.11 MB out of 14334.00 MB, Memory: Used 3462.00 MB out of 7167.00 MB, CPU: Usage 100.00%
##[debug]Agent environment resources - Disk: D:\ Available 7350.92 MB out of 14334.00 MB, Memory: Used 3416.00 MB out of 7167.00 MB, CPU: Usage 71.00%
##[debug]Successfully created archive D:\a\1\a\(MyApplicationFolder).zip
##[debug]rm -rf D:\a\1\a\(MyApplicationFolder)
##[debug]removing directory D:\a\1\a\(MyApplicationFolder)
D:\a\1\a\(MyApplicationFolder)\(MyDLL).dll - The process cannot access the file because it is being used by another process.
##[error]Error: Failed rmRF: EPERM: operation not permitted, unlink 'D:\a\1\a\(MyApplicationFolder)'
##[debug]Processed: ##vso[task.issue type=error;source=TaskInternal;correlationId=c0963811-2fe9-464a-8c33-66fc66a22461;]Error: Failed rmRF: EPERM: operation not permitted, unlink 'D:\a\1\a\(MyApplicationFolder)'

Full task logs with system.debug enabled

No response

Repro steps

- task: DotNetCoreCLI@2
        displayName: Publish
        inputs:
          command: publish
          publishWebProjects: false
          projects: '$(buildProjects)'
          arguments: '--configuration $(buildConfiguration) --output $(build.artifactstagingdirectory)'
          zipAfterPublish: true

[MantavyaDh]

This is not a regression as the feature flag to use the latest 7zip is not turned on yet. Also the task doesn't use 7zip for zip operations. To investigate further need some info as it, can you share which MS Hosted Pool (OS) are you using ?

[jamesrock-asinpa]

Thank you for those details. I believe what you are looking for is this?

[spowser]

We are also seeing this behavior trying to publish our build assets. It just started happening 4hrs ago with no changes on our side

- task: DotNetCoreCLI@2
              displayName: "Publish deployable projects"
              inputs:
                projects: |
                  src/project.csproj
                command: "publish"
                nobuild: true
                publishWebProjects: false
                zipAfterPublish: true
                versioningScheme: "byBuildNumber"
                modifyOutputPath: true
                arguments: "--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)"

We are using Managed DevOps Pools with the Azure Pipelines - Windows Server 2022 image set

[dmmusil]

The workaround of setting zipAfterPublish: false and handling the zipping ourselves appears to work.

[dmmusil]

This broke for us on 2.264.1 as well, so I'm thinking it might be something that changed in the runner image.