ASP.NET and ASP.NET Core Application Restarts on Azure App Service.

[finbarrryan]

First published on MSDN on Aug 02, 2017
Your ASP.NET \ASP.NET Core application on Azure App Service will restart for many of the same reasons that it would do on an on-premises IIS Server or VM hosted in the cloud.

Here are some of the reasons that this will happen.

• The IIS worker process is recycled.


• The worker process terminated unexpectedly.


• The App Domain is restarted because a file has been changed.

The first item is expected and will generally be a user initiated action.
The second item is unexpected, and your diagnostics logging should make you aware of this and help you understand what actions to take.

Let's take a moment to concentrate on the third item which is all about ASP.NET and File Change notifications.

Asp.Net will monitor your application for file changes so that the mark-up or code changes are instantly reflected in requests from your users. This article has a great summary of the ASP.NET file change notification (FCN) structure.

In Azure App Service your site content is hosted on Azure Storage. From the Azure App Service Architecture article you will see that your application will run on a Worker role and will access the files via the File Server Role.

"A file server mounts Azure Storage blobs and exposes them as network drives to the Worker. A Worker, in return, maps such network drives as local, allowing any application running on any given Worker to use the 'local' drive, just like you would expect if the application were running on a server using its local disk. Any file-related read/write operation performed by the application passes through a file server."

To help protect the Azure App Service infrastructure the product group have implemented a feature named Dynamic Cache. This feature runs on the worker and acts as an intermediate layer helping manage the read\write operations for the site content on the File Server.

This feature is continually monitored and updated as part of regular maintenance. In July 2017 an update to this feature resulted in the following issues.

• The ASP.NET \ASP.NET core process would terminate unexpectedly. This was related to long paths used by the application of 260 characters.


• The update correctly propagates file change information (including the App_Data folder) to the application. However some applications make extensive use of the App_Data folder internally and this can lead to overwhelming change notifications for ASP.NET .


• A recently updated application will work for 10 to 15 minutes and then log a message "The configuration file has been changed by another program".

Workaround and next steps.

This article will be updated once the three items listed above have been resolved via an Azure App Service update. If you are affected by one or more of the issues listed above, then please use one or both of the actions below.

• Restart your web site


• Set an application Setting called WEBSITE_DYNAMIC_CACHE and set its value to 0.

You should not notice any performance implications when you set this application setting.

Please note that if you are not affected by these issues then please do not set the application setting.

If you are continuously deploying to Azure App Service, then you may need to disable the Dynamic Cache setting and should consider the following scenario.

1. Set up a Staging Environment as discussed at this link https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing


2. Add the Sticky App Setting WEBSITE_DYNAMIC_CACHE with the value 0 to the Production Slot.


3. Add the Sticky App Setting WEBSITE_DYNAMIC_CACHE with the value 0 to the Staging Slot.


4. Deploy your updates to the Staging Slot.


5. Test your site against your Staging Slot.


6. When you are ready, issue a swap operation between your Staging and Production slots.

This setup will mean that you are not going to run into these issues and you will avoid the need for site restarts.