Closed danjagnow closed 2 years ago
Workaround: I was able to open the Kudu Remote Execution Console and delete the wwwroot folder under site:
/home>cd site
/home/site>rm -r wwwroot
After that, the deployment proceeded with the .NET 6 flavor of the application.
Oh, and I had to update from .NET 5 to .NET 6 under General settings under Configuration to make sure the correct framework was installed.
This issue is idle because it has been open for 14 days with no activity.
@danjagnow we will investigate this case. Between - did you try recently and is the issue still happening?
@danjagnow we will investigate this case. Between - did you try recently and is the issue still happening?
After the workaround I described above, I haven't encountered any further issues. I have been able to deploy several other changes to Azure with a .NET 6 codebase without further problems. But since at least one other person has encountered similar symptoms, I thought it would be helpful to document the issue.
@danjagnow we will investigate this case. Between - did you try recently and is the issue still happening?
After the workaround I described above, I haven't encountered any further issues. I have been able to deploy several other changes to Azure with a .NET 6 codebase without further problems. But since at least one other person has encountered similar symptoms, I thought it would be helpful to document the issue.
Thanks for info @danjagnow. For now, I am closing this case, if you happen to encounter it again, you can reopen it.
We are encountering this on PHP 8. Removing the site directory is an unacceptable workaround - if a workaround at all - because that breaks the service itself, of course. Please re-open this issue (you may contact me for feedback and a repro). Otherwise, suggest a proper workaround. Thanks, cc @AyoAyomide
I am encountering this same issue. I just updated a .net core 3.1 api to .net core 6. My error message is nearly identical to that of the original posters. I agree with rvvincelli that deleting the site directory is an unacceptable workaround. Even if deleting the site directory was acceptable as a workaround... the issue remains and this error should not have been closed.
@MrGoodfix We were able to pinpoint the issue and find an acceptable workaround, finally. The issue is: the release script does not handle symlinks properly. Not really blaming anyone here, since symlinks are a notorious complication in Git already, and they are system-dependendent. Our solution is: avoid the symlink altogether.
This is Composer-specific for our Laravel project, but I guess it can be done in any other build system etc. In the repositories
array we have added an extra symlink
property, like this:
{
"type": "path",
"url": "./nova-components/Sharesquare",
"options": {
"symlink": false
}
}
this forces the build to copy the contents of the component dir, rather than symlinking it. With this fix in place we have not encountered any other issues.
The Azure script should not fail in the first place, yet this is an acceptable workaround. cc @ayoayomide
I have an ASP.NET Core Web Application based on .NET 5 that uses azure/webapps-deploy to deploy to Azure. After updating the application to .NET 6, the Azure deployment fails. The app runs fine locally on a Windows workstation.
My GitHub Actions YAML looks like this (with the app name changed):
The only change to that with the .NET 6 update was the
dotnet-version
, which changed to 6.0.100. There were several changes in the application itself, but those all compile and run normally. During the deployment step, I now get an error:I tried adding a hack to delete the offending file from under the ./app folder immediately after the
dotnet publish
, but the error just moved to a different file. See also https://stackoverflow.com/questions/69967124/azure-app-service-net6-deploy-error-eisdir-illegal-operation-on-a-directory for another user encountering a similar issue after a .NET 6 upgrade. Any ideas about what might be going wrong?