Zip deploy fails on backslahs in package

Question

Zip deploy fails on backslahs in package

Bart Teirlynck 0

Recently i setup a new release pipeline for a product that, in my eyes looks identical, to another release but for a different app service.

The deploy fails and whe i look at some deployement logs this catches my attention.

{"timestamp": "2024-08-01T08:07:59.057Z", "level": "Message", "containerName": "aar-70-000_kudu_2a94d01e8d", "machineName": "lw0sdlwk0005TX", "message": "Copying file: 'Reports\\Template.repx'"}
{"timestamp": "2024-08-01T08:07:59.097Z", "level": "Message", "containerName": "aar-70-000_kudu_2a94d01e8d", "machineName": "lw0sdlwk0005TX", "message": "Error: EINVAL: invalid argument, open '/home/site/wwwroot/Reports\\Template.repx'"}

For some reason during extraction of the zip packages, the file Template.repx isn't correctly handled.
It should defenitly be 1 forward slash instead of 2 backslashes. But i can't figure out why the deployement procedure with upack the zip file wrong or interpret that file in a folder in a wrong manner.

I mean it's a zip file, it's not like i have any control over the unpacking process that would unpack a folder incorrectly.

When i look at the logs of the ather apps ervice it handles this file correctly. Both are Linux app services. They are in different regions though.

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

Christos Panagiotidis 3,546 Reputation points

2026-07-30T05:53:41.9566667+00:00

The failure indicates that the ZIP already contains an entry with backslashes, such as Reports\Template.repx. On Linux, a backslash is a literal character rather than a directory separator, so Kudu cannot extract that entry into the expected folder. This is an artifact-generation issue, not an App Service region setting. Inspect the exact package from the failing pipeline and compare its entry names with the working package. Regenerate it so every ZIP entry uses forward slashes, for example Reports/Template.repx. A reliable pattern is to run dotnet publish, enter the publish-output directory, and archive its contents with a ZIP tool that writes standard separators; do not archive the project using a custom Windows path list. Delete the bad artifact and deploy the rebuilt ZIP. If all entries already use forward slashes, retain the deployment ID and Kudu log and open Microsoft Support, because extractor behavior would then contradict the package.

Christos Panagiotidis 3,546 Reputation points

2026-07-30T05:53:41.9566667+00:00

The failure indicates that the ZIP already contains an entry with backslashes, such as Reports\Template.repx. On Linux, a backslash is a literal character rather than a directory separator, so Kudu cannot extract that entry into the expected folder. This is an artifact-generation issue, not an App Service region setting. Inspect the exact package from the failing pipeline and compare its entry names with the working package. Regenerate it so every ZIP entry uses forward slashes, for example Reports/Template.repx. A reliable pattern is to run dotnet publish, enter the publish-output directory, and archive its contents with a ZIP tool that writes standard separators; do not archive the project using a custom Windows path list. Delete the bad artifact and deploy the rebuilt ZIP. If all entries already use forward slashes, retain the deployment ID and Kudu log and open Microsoft Support, because extractor behavior would then contradict the package.