I've been having trouble trying to get Azure diagnostics to work since upgrading to 2.5. I went through the steps here, but I get no data from my cloud service until I click on the role in the server explore, enable diagnostics, and fill out the form again. Any ideas on how to fix this? Since I have to do it each time I deploy (manually) it's a pain.
edit: It looks like this only is failing with powershell deploy, but deploy from VS is working correctly. I'm guessing there are some new calls to make to enable diagnostics from powershell deploy.
The steps at http://blogs.msdn.com/b/kwill/archive/2014/12/02/windows-azure-diagnostics-upgrading-from-azure-sdk-2-4-to-azure-sdk-2-5.aspx should help, in particular the last section which shows how to do this via Powershell.
Related
I am trying to use Azure DevOps pipelines to build a .NET 5 (Core) web app and deploy it to my Azure app service. I can't find any complete examples in the documentation that achieve this so I'm following this:
https://github.com/shahedc/NetLearnerApp/blob/main/azure-pipelines.yml.txt
However, the Azure deploy task keeps returning this vague error:
In my Azure portal I only get this error:
I am assuming the issue is in my pipeline because deployment works when I deploy it directly from the Deployment Center in the Azure portal. Here are the details for the 3 relevant tasks my pipeline:
I found the solution. It turns out the issue was not in the pipeline, but was caused by a Git connection to the app service I had previously set up in the Azure Deployment Center. Even though I disconnected/removed this Git connection, there was somehow still a residual file left over in Azure that was causing the error. I deleted the 'deployments' folder in Kudu (pictured below) and the pipeline started working as expected.
Getting to the above pictured view:
Navigate to your Azure Function project
Search for Advanced Tools
Open PowerShell
Check if you have disk space available.
Yesterday we started getting this error, even if we tried to re-deploy packages that were successfully deployed just an hour before. Our system guys checked and found out that we reached the space limit and that it was time to upgrade.
P.S. I know that this was answered a long time ago. I am just sharing the solution that was not mentioned here and that worked for us.
think what Dan Beaulieu said in above answers is correct, but one thing to add, in my case, after deleting the deployments folder, remember to restart the app service/web app, which will make it take effect.
I have a working azure web app, I cant deploy anything when I click Deployment center it just stuck at Fetching deployment data
If I wait for while I get this:
I have to mention that I had apps before on azure and everything worked smooth.. the only difference between the apps is that the broken app I created with azure VS extension.
all the apps are configured to auto-deploy from Bitbucket
For me, there wasn't enough space on the disk. I saw this "lack of space" error message after clicking Deployments in Kudu (Advanced Tools in your web app). I deleted the LogFiles folder to free up space and everything went back to normal.
I had the same problem with deployment sticking/breaking when I was trying to use the F (free) tier. I was trying to push a .NET Core app with https: support enabled in the app. Because the F tier does not support SSL, it broke everything and there was no trace to say what the problem was. Not sure if this was your problem as well, but if anyone is trying to do the same thing that I did, I hope this is helpful. Changing to an S (standard) tier fixed it. I suppose disabling https: support in the app you are trying to push would work as well, but I did not try that approach.
This happened to me last night. Finished up some changes to an API and front end app. API published to app service without issue from Github pipeline. Front end app would not publish. Error was:
Deployment Failed with Error: Error: Failed to deploy web package to App Service. Conflict (CODE: 409)
Same issue as here. The deploument center would never load and eventually would give me a Gateway Timeout error. Two hours I spent trying to figure out what was wrong. Even opened a support ticket. It was a problem with the Azure service that was resolved by the next morning.
I am trying to chance some appsettings and the ConnectionString of an application in a certain slot in my Azure Web App.
When I try to change the config via the Application Settings on Azure portal, nothing happens.
So I found this post:
http://brian.vallelunga.com/blog/chaining-azure-web-config-transforms-when-deploying-from-source-control
Ok, I done what the tutorial tells me to do and I got success on some deploys (I am using Kudu for auto deploy from GitHub).
But suddenly (without any change of config) the deploys are using the Release transform, instead of the dev one.
Via Kudu console, I saw in deployment folder, in some moment Kudu transformed my web.config in right one, and after transforms it again into the release version.
Someone have any idea what I can do?
Oh. My solution have more than one web project. I am using the "Project" Key on Azure application config page and that one works.
Thanks,
Ok guys, found the answer.
For some strange reason, the value of the parameter SCM_BUILD_ARGS changed from /p:Environment=Staging to -p:Configuration=Debug.
I just passed that value on Azure app settings and voil! It's working now :)
I'm getting the following error while trying to publish an Azure cloud service (classic) from Visual Studio:
There's so little information in that error that I have no idea what to start fixing. Is there a more detailed log somewhere, and what steps (if any) need to be taken to enable it?
The solution for me that works is to refresh the Azure connection. I use for that the Server Explorer - expand the needed service branch lead to the solution.
The solution can be refresh the credentials as well. It may be connected with the Visual Studio or Azure SDK versions, so it is worth to try to start from reinstalling at least Azure SDK.
We have a bug in our WebJob running in our live environment, I have identified the bug and fixed it, this I can verify in our Dev-environment. I published my WebJob as a "Azure WebJob" to our live environment but the bug i still present. To add to the confusion the bug now just occurs sometimes. So for some reason the old code is running somewhere sometimes.
Can someone please help me understand this?
I had a similar problem. We deploy using a stage environment in Azure and it turned out that the "old" WebJobs (running code with an old version of the entity framework model) where still running on the queue. These jobs where then fetching messages and consuming them. To add to the problem the exception was consumed in a try catch and the status of the WebJob was success.
Check if you have a stage environment (add -stage to the Webapp name) and if so go in to the Azure management portal and stop them.
Note, it is not enough to stop the Webapp, you must stop the WebJobs directly. This is done (in the new portal) under Settings->WebJobs and then right-clicking on the webjobs name selecting stop.
I spent ages looking into this problem. Turns out I had the web job project running in a console on my PC at work! No matter what I did on Azure the presence of this exe running and using the same storage for the web jobs meant that the old code running on my work PC picked up the jobs before Azure did. Easy fix: just make sure no exes are running outside of Azure!
In our case the web app was published to physical path /site/www instead of the default /site/wwwroot, because of this the Azure web portal interface adds the WebJobs to folder /site/jobs, but the webdeploy via VS or Azure are still trying to publish the webjobs inside the /site/www.
More details at Publishing WebJobs with Azure Pipelines