I am developing a multi-tier web application consisting of multiple Web APIs in an Azure App Service Environment.
Recently after upgrading to VS2017 I have noticed that the apps will randomly fail to update after I publish new code (from VS). Remote debuggers will not load correctly and the old code will continue to run after publishing.
I am selecting "Remove additional files at destination" in the publish settings.
Restarting the apps usually fixes the problem temporarily, though sometimes I have to stop and restart each app.
Are there any new settings in VS or Azure that could be affecting this behavior, or is something just not working correctly?
WEBSITE_DYNAMIC_CACHE is new feature that, for some reason, was turned on by default.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
This worked for me:
In VS 2017 right-click on the project and choose Publish.
Click on Configure, as shown below:
I had WEBSITE_LOCAL_CACHE_OPTION 'Always' on for my Production Slot within Application settings. When I created a new slot I copied the settings from the Production slot - including this flag. This had to be turned off for Staging.
Try this WEBSITE_RUN_FROM_PACKAGE = 0 in my case its helps.
Adding the entry to Application Settings in the Azure Portal and setting the value to 0 seems to have solved the problem.
The issue maybe related to the dedicated instances in your ASE. You could submit a support request if you have a support plan.
As a workaround, you could set up a new Worker Pool in your ASE or a new ASE and create a new Web App Plan there. After that, you could move your Web App to the new Web App Plan. Your Web App will run on the new allocated instances. It will solve the issue which related to the dedicated instances.
Related
Currently when pushing updates via our CI/CD pipeline to the Azure Web Apps the nodes are being forcefully rebooted by azure once the configuration changes are completed.
Has anyone come across a way where you can apply a configuration (web.config or other) changes to the web app in a single slot configuration with out the forced restart?
As Fabrizio Accatino said, when you touch the web.config, IIS automatically restarts the app domain.
If you do this to avoid downtime, you could add a deployment slot and publish your newest project to it. When you want to publish your project to production environment,you can swap them.For more details, refer to this article.
If downtime is your concern, it looks like MS starts up another container when you hit Save in the application settings blade, and then transfers all new requests over to the new container. The old container is given 2 min to complete all requests, and is then shut down.
https://social.msdn.microsoft.com/Forums/azure/en-US/f15b207b-c063-46e5-b87a-2b157641c8c4/does-changing-an-app-setting-and-saving-restart-the-app?forum=windowsazurewebsitespreview
I tested this on a Web App by repeatedly hitting an endpoint for 30 seconds while I changed an application setting and hit save. I saw the application start, but did not see any timeouts, only 200 OKs.
FYI my web app only used a single slot.
I'm trying to learn how to deploy Web Application to Azure using Visual Studio 2015. I could successfully deploy a simple Web Application (without creating any slot). I moved to the ARM portal and found that there isn't any slot. However, when I try to swap, I can see "production" as an option in the source & destination drop down lists.
I created another slot and then I tried to publish the Web Application again, but I could only see one slot, which is the newly created slot (please see the screen shot)
I'm a bit confused. According to my understanding, there should be a default slot which I can deploy specifically to it and then swap to/from it.
Any ideas?
As far as I know, the "TestWithDB20170822062605" application is your default application. You could directly select this web app. If you publish the application to this. It will be regard as production app.
If select the TestWithDBSlot2, it will publish the application to your newly created slot.
Firstly, if you select the "TestWithDB20170822062605" application, VS will publish the application to the TestWithDB20170822062605.azurewebsites.net.
This is according to the url not the slot or something else.
But if you swap the web app.
It will like this
TestWithDB20170822062605.azurewebsites.net --------> TestWithDBSlot2
TestWithDBSlot2.azurewebsites.net -----------> Production
So you will find you publish the application to the slot TestWithDBSlot2, but the url is still TestWithDB20170822062605.azurewebsites.net. This is according to the url not the slot name.
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
We are using continues deployment from Visual stdio online to an Azure Website.
The deployment fails when we added new relic.
"Exception Message: The file 'NewRelic.Profiler.3640.log' is in use."
If I Disable profiling, azure website>configure>app settings COR_ENABLE_PROFILING = 0 then the deployment works.
Is there some way to get this to work? Is it possible to add a step to the deployment process that sets COR_ENABLE_PROFILING = 0 and then afterward set COR_ENABLE_PROFILING = 1.
This is a known limitation of New Relic's Azure Web Sites integration:
https://docs.newrelic.com/docs/dotnet/azure-web-sites#known_issues
I'm not sure if setting that Web Site app setting after deployment is possible or would cause the profiler to load. With other types of deployment for the New Relic .NET agent, IIS needs to be restarted for the profiler to load into the web worker process. The COR_ENABLE_PROFILING environment variable is just a flag that more or less gives the profiler permission to load. So I think the site would require a restart even if you could set the variable later.
Making it possible to use continuous deployment with New Relic and Azure Websites would require some coordinated effort between New Relic and Microsoft. You might file a feature request with both.
I was able to make the continues deployment work. If i copied the new relics folder out of the sites folder. And the change the new app config to use that one the site and deployment work. Not 100 % sure that new relic works but it seems to be doing alright
I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.