Unable to use Web App Deployment
nilsanderspersson opened this issue · 38 comments
After the update to version 4 (now using 4.1), I can no longer publish to the Web App with dotnet 8. Firstly, it just says Runtime: UNKNOWN. When I then try to publish, it gets stuck on "Trying to deploy artifact to [myserver]". When I check the publishing log in Azure, it now says "OneDeploy," and it hangs there until I cancel the publication in Rider. Before version 4, this process only took a few minutes, and the log indicated that it was published as "Created via a push deployment." I need to resolve this because we currently can't publish at all. I've tried installing all versions from 4.0.0 to 4.1.0.
Is there any way to install version 3 again? Otherwise, I'll unfortunately have to switch to Visual Studio, and I really don't want to do that.
Hello!
Firstly, it just says Runtime: UNKNOWN.
This is a known bug, it doesn't affect deploymenet. We will fix it.
Is there any way to install version 3 again?
For Rider 2024.2 and later there is no way.
Could you please collect logs (via Help | Collect Logs) and attach them? I will take a look.
Here are the logs
rider-logs-20240826-08412712849626547597996844.zip
Same problem here. Unable to deploy to Azure Web App. When looking at the run/debug configurations, the existing profiles show up under Unknown, and this message: Run Configuration Error: Broken configuration due to unavailable plugin or invalid configuration data. I tried rolling back Rider 2024.1.x. But I'm stuck with the Azure Toolkit for Rider 4.1.0. So proceeding now with Visual Studio since I need to deploy now.
Same here, we publish daily, and now we get to use Visual Studio until this is fixed
How is this going? Is there a plan to fix this bug?
@nilsanderspersson Unfortunately, I can't reproduce this problem on my side. And I don't see any suspicious logs. Maybe there is something in the environment variables; do you have any Azure related variables?
This typically is the 'works on my pc' problem, hard to nail it down this way. To summarize, the old "Publish Web App" are broken and are moved the the "Unknown" folder. But I gave it another try. I uninstalled the plugin, managed to install the 4.0.0 version. Logged in to Azure, selected all tenants. Now I am able to select one of the web apps (from my tenant). I reinstalled 4.1.0. Now i In the dropdown to select the Web App I see the web apps, runtime is set to UNKNOWN. But at least I can publish now from within Rider, which helps.
I also noticed a review for the plugin:
"WARNING They changed the default publish type. Also login using oauth 2.0 seems broken.
The newest 4.1.0 release changed the default publish to AzureWebAppDeploy vs. AzureDotNetWebAppPublish.
The default of AzureWebAppDeploy is to delete all files on the app service! Good we always publish to a dev container first else this would have blown away all our files in our web application in prod."
Maybe this can be taken into account.
@nilsanderspersson Unfortunately, I can't reproduce this problem on my side. And I don't see any suspicious logs. Maybe there is something in the environment variables; do you have any Azure related variables?
Note that we are publishing to a slot.
This is our environment variables, nothing strange here.
Have you tried to create a WebAPI project running dotnet 8 to a Azure instance runnning Dotnet 8 (Linux)?
For me, the problem exist on all 3 computers, 1 running Mac OS and 2 running Windows 11.
@mebrein
Yes, unfortunately the old publish configurations don't work because the plugin was rewritten with sctratch and we had to make those changes. I'm sorry for that.
runtime is set to UNKNOWN
This is a presentation bug only, it doesn't affect the deployment. We will fix it soon.
The default of AzureWebAppDeploy is to delete all files on the app service
I've already fixed this issue #904. The fix will be available soon.
Also login using oauth 2.0 seems broken
I described some details about this bug and possible workarounds here #884. I'm going to further investigate and fix this in the near future.
@nilsanderspersson Thanks! Indeed, nothing special. Yes, I've tried dotnet 8 web API applications with Linux OS (and Windows OS too) and a deployment slot. Could you please try deploying a template solution? Also, there should be the deployment logs, could you please check if there is something there?
Hi again
Just updated Rider and installed Azure Plugin 4.1.0 to give it a new try.
There is more problem. When im trying to Login using 0Auth
When trying to login using Device Login
Logs
Uploading rider-logs-20240902-15345212424668939498235561.zip…
It's known bug #884. It occurs due to a third-party library that is used for authentication in Azure. I'm going to investigate it. As a workaround, you can use the Azure CLI login or disable the authentication cache in the Settings.
Still the same problem, login was success using the Azure CLI but the 0Auth2 and Device doesnt work.
I have also removed all publishing profiles and re-created them. Also deleted the .idea folder in the root.
Then i created a new publishing profile to Azure, select the profile then clicked run.
After 20 minutes, Rider still runs the profile and this is the screenshot from Azure
is there any way to publish version 3 so that it works with the new version of Rider?
No, unfortunately, due to some breaking changes in the IntelliJ Platform, version 3 is not compatible with Rider 2024.2 and later
I think I found the issue. When this deployment succeeded, the Azure logs became available in Rider. The problem was this: A suitable constructor for type 'Jobbs.Infrastructure.Security.JobbAppVersionMiddleware' could not be located.
After fixing that line of code, the deployment went smoothly again.
This is strange, the logs says A suitable constructor for type 'Jobbs.Infrastructure.Security.JobbAppVersionMiddleware' could not be located. Ensure the type is concrete and services are registered for all parameters of a public constructor.
But all services i registrated and the app running fine both in debug and release.
See the attached log
A few questions:
- Is it your
Jobbs.Server.dll
or does it come from some library? - Is it your
Jobbs.Infrastructure.Security.JobbAppVersionMiddleware
or is it from some library?
There should be a log with the .zip
artifact when you deploy it. You can try copying it somewhere, unzipping it and running it with the same dotnet Jobbs.Server.dll
command. Will it work?
Rider simply uses dotnet publish
and packs the resulting folder into a zip archive. Do you see the difference between the files?
Now I've tested more, and the release works from the zip file. It was just that it didn't produce any output, but it starts and works as it should. So it's only when I publish that this error occurs. Do you have any ideas on how I can troubleshoot this further?
Here is the logs when using Visual Studio
2024_09_03_lw1sdlwk0006AF_default_docker.log
Is there anyway to get the startup.sh file?
Now I have tried everything from step 1. Publishing to Azure 2. After 40 minutes, Rider is still publishing, and in Azure, it says that the application is being built. 3. I stop the publishing in Rider, and after about 20 minutes, Azure has stopped building the application. During this time, I am logged in via SSH and cannot see any files under wwwroot. 4. I retrieve the log, which you can see here.
Is there anything else i can do to help you toubleshoot?
I need some time to experiment with some ideas
Yes, thank you. Please let me know if there is anything else I can do to help.
I've had some "completed" deploys that weren't actually deployed.
I tried many deploys yesterday (after sorting the login etc. issues). First two were fine. However, I made numerous attempts after that. All said deployed successfully, but changes weren't there. Looking at the Azure logs, I'd got two "OneDeploys" yesterday (the ones that had worked), and no record of the others, although it showed one failed deploy. When I looked on the console, it clearly hadn't replaced the files.
Installed R2024.1.6 and 3.50.0.1784-2024.1 Tools this morning, and deployed first time.
This morning the logs show the two that worked yesterday and the latest 3.50 deploy. However, the failed one has disappeared.
This PR #909 should probably fix all the problems. I've reverted back to zip deployment. Why did we switch to a different deployment mechanism in the v4 plugin? As you may know, our plugin is a fork of the Microsoft Azure plugin for Java developers, so we use many of the features of the Java plugin. And they use this OneDeploy
deployment mechanism. But it probably doesn't work well enough for .NET projects (I couldn't find any documentation about what OneDeploy
is and how it differs from zip-deploy). So I decided to just revert back to v3 behavior. Now everything should work the way it did in the v3 plugin.
I tested on my small projects and it works. But I would ask you to test this plugin build and give me feedback if it works as expected on your real-world projects. Here is the link to the built plugin https://github.com/JetBrains/azure-tools-for-intellij/actions/runs/10719085818/artifacts/1895755740. To install it, just use this menu and choose the azure-toolkit-for-rider-4.1.3.zip
archive.
I'm really sorry that the v4 plugin has broken your workflows, and I hope the fix helps.
I can confirm that publishing to Azure is now working again with version 4.1.3. Thank you for your help.
Thank you for testing. Then I'll publish a new version today.