<p>The answer is no, <strong>if you are using the <a href="https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache#best-practices-for-using-app-service-local-cache" rel="nofollow noreferrer">recommended setup</a></strong>, which is:</p>

<ul>
<li>App Service should have Staging and Production slots</li>
<li>Staging slot has Local Cache disabled</li>
<li>Production slot has Local Cache enabled</li>
<li>The following settings are configured as "Slot setting" aka "Sticky setting" - WEBSITE_LOCAL_CACHE_OPTION, WEBSITE_LOCAL_CACHE_SIZEINMB</li>
<li>The code is deployed to Staging slot</li>
<li>Staging slot is swapped with Production slot</li>
</ul>

<p>For deployments to Staging, I created the following steps:</p>

<ol>
<li>Shut down Staging slot by introducing App_Offline.htm (POST to SCM URI or can be part of artifact being deployed)</li>
<li>Wait for slot to stop before cleaning (probe the URL of Staging slot)</li>
<li>Cleanup wwwroot (post to SCM URI) - this is to clean unused files. Deployments <a href="https://github.com/projectkudu/kudu/issues/2103#issuecomment-240768840" rel="nofollow noreferrer">are not incremental</a>, so if it's important to have clean old files, you can introduce this step.</li>
<li>Deploy to Staging slot using <code>az webapp deployment source config-zip</code></li>
<li>Remove App_Offline.htm (POST to SCM URI)</li>
</ol>

<p>For swapping slots:</p>

<ol>
<li>Check Staging slot is up and ready (probe the URL of Staging slot) - this one is useful when triggering deployment environments in Atlassian Bamboo when deployed to Staging. You need to wait for Staging to be up and loaded before swapping, otherwise issues may occur</li>
<li>Swap the slots using <code>az webapp deployment slot swap</code></li>
</ol>

<p>If you deploy directly to Production slot, and restart it right after (because of Local Cache enabled), then yes, there should be no file locks when using this method. But this creates the downtime during deployment, in contrast with deployments to Staging slot and swapping it with Production.</p>

CC BY-SA 4.0
2020-09-01T20:49:37.187Z
If you have WEBSITE_LOCAL_CACHE_OPTION set to Always for the Production slot only but then deploy to staging using `az webapp deployment source config-zip` and swap with Production -- wouldn't you then run into the aforementioned incompatibility between WEBSITE_RUN_FROM_PACKAGE=1 and WEBSITE_LOCAL_CACHE_OPTION=Always as detailed in the links in the original post? 

Basically, when these two configuration values are present, it causes the app to crash shortly after startup as it attempts to write to its local filesystem which is now readonly due to running from a zip package.
Mushkov
CC BY-SA 4.0
2020-09-02T22:58:19.910Z
@Mushkov In my environment I stopped using WEBSITE_RUN_FROM_PACKAGE=1 because it's incompatible with WEBSITE_LOCAL_CACHE_OPTION=Always .
The point of WEBSITE_RUN_FROM_PACKAGE=1 in my case was avoiding file locks. Instead, I introduced App_Offline.htm to gracefully stop the staging slot before deploying to it. I hope my comment makes sense, if not, please let me know and I will elaborate on it.
Alex
CC BY-SA 4.0
2020-06-17T23:08:35.200Z
2020-06-17T23:08:35.200Z
Alex
<p>During the deployments, occasionally I experienced issue with files being in use by App Service and thus not overwritten with newer versions.</p>

<p>There are <a href="https://docs.microsoft.com/en-us/azure/app-service/deploy-zip#what-happens-to-my-app-during-deployment" rel="nofollow noreferrer">multiple recommendations</a> to overcome this problem:</p>

<ul>
<li>Run your app from the ZIP package directly</li>
<li>Stop your app or enable offline mode for your app during deployment (using App_Offline.htm)</li>
<li>Deploy to a staging slot with auto swap enabled.</li>
</ul>

<p>I am exploring the <a href="https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache" rel="nofollow noreferrer">local cache option</a>, to fix a different problem, and it is not compatible with running from ZIP feature, as discussed <a href="https://github.com/Azure/app-service-announcements/issues/84" rel="nofollow noreferrer">here</a> and <a href="https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package#troubleshooting" rel="nofollow noreferrer">here</a> </p>

<p>If I understand correctly, when using local cache, the ZIP with code is deployed to Storage Account, and then is loaded into memory on App Service restart.</p>

<p>Does this mean, the issue with locked files is eliminated by using local cache, since the code is not run from the same place where it's deployed to?</p>

CC BY-SA 4.0
2020-06-15T22:18:00.100Z
Created a support ticket in Azure, asking the same question. So far, I have not received any useful response. Support is sending links about ZIP deployments and Local cache. According to them, local cache does not solve the problem with locked files, but without explanation. Also, there were no comments on compatibility for these two features. Will update the ticket once I learn more.
Alex
CC BY-SA 4.0
2020-06-16T19:01:58.117Z
Support confirmed incompatibility of Local Cache and Run From Package features.
Alex
CC BY-SA 4.0
2020-06-16T19:07:10.217Z
I reviewed the configuration on my end. Production slot of App Service has Local Cache enabled. Staging slot, however, has Local Cache disabled, as recommended in Microsoft documentation. This means, the apps in Staging run directly from the durable shared content store, meaning there can be file locks. My impression is, if I deployed directly to Production slot with Local Cache, then locking wouldn't be an issue. But in my scenario, I will be introducing App_Offline.html file when deploying to Staging to avoid file locking.
Alex
<azure>
Does local cache solve the problem with locked files when deploying to Azure App Service?
Alex
# Does local cache solve the problem with locked files when deploying to Azure App Service?

(Asked by: username_0 on 2020-06-12)

During the deployments, occasionally I experienced issue with files being in use by App Service and thus not overwritten with newer versions.

There are [multiple recommendations](https://docs.microsoft.com/en-us/azure/app-service/deploy-zip#what-happens-to-my-app-during-deployment) to overcome this problem:

* Run your app from the ZIP package directly
* Stop your app or enable offline mode for your app during deployment (using App\_Offline.htm)
* Deploy to a staging slot with auto swap enabled.

I am exploring the [local cache option](https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache), to fix a different problem, and it is not compatible with running from ZIP feature, as discussed [here](https://github.com/Azure/app-service-announcements/issues/84) and [here](https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package#troubleshooting)

If I understand correctly, when using local cache, the ZIP with code is deployed to Storage Account, and then is loaded into memory on App Service restart.

Does this mean, the issue with locked files is eliminated by using local cache, since the code is not run from the same place where it's deployed to?

**Tags:** azure

> **Comments:**
> **username_0**: Created a support ticket in Azure, asking the same question. So far, I have not received any useful response. Support is sending links about ZIP deployments and Local cache. According to them, local cache does not solve the problem with locked files, but without explanation. Also, there were no comments on compatibility for these two features. Will update the ticket once I learn more.  
> **username_0**: Support confirmed incompatibility of Local Cache and Run From Package features.  
> **username_0**: I reviewed the configuration on my end. Production slot of App Service has Local Cache enabled. Staging slot, however, has Local Cache disabled, as recommended in Microsoft documentation. This means, the apps in Staging run directly from the durable shared content store, meaning there can be file locks. My impression is, if I deployed directly to Production slot with Local Cache, then locking wouldn't be an issue. But in my scenario, I will be introducing App_Offline.html file when deploying to Staging to avoid file locking.  

---

## 1 answers

### Answer by username_0 on 2020-06-17. Score: 1 | Accepted answer

The answer is no, **if you are using the [recommended setup](https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache#best-practices-for-using-app-service-local-cache)**, which is:

* App Service should have Staging and Production slots
* Staging slot has Local Cache disabled
* Production slot has Local Cache enabled
* The following settings are configured as "Slot setting" aka "Sticky setting" - WEBSITE\_LOCAL\_CACHE\_OPTION, WEBSITE\_LOCAL\_CACHE\_SIZEINMB
* The code is deployed to Staging slot
* Staging slot is swapped with Production slot

For deployments to Staging, I created the following steps:

1. Shut down Staging slot by introducing App\_Offline.htm (POST to SCM URI or can be part of artifact being deployed)
2. Wait for slot to stop before cleaning (probe the URL of Staging slot)
3. Cleanup wwwroot (post to SCM URI) - this is to clean unused files. Deployments [are not incremental](https://github.com/projectkudu/kudu/issues/2103#issuecomment-240768840), so if it's important to have clean old files, you can introduce this step.
4. Deploy to Staging slot using `az webapp deployment source config-zip`
5. Remove App\_Offline.htm (POST to SCM URI)

For swapping slots:

1. Check Staging slot is up and ready (probe the URL of Staging slot) - this one is useful when triggering deployment environments in Atlassian Bamboo when deployed to Staging. You need to wait for Staging to be up and loaded before swapping, otherwise issues may occur
2. Swap the slots using `az webapp deployment slot swap`

If you deploy directly to Production slot, and restart it right after (because of Local Cache enabled), then yes, there should be no file locks when using this method. But this creates the downtime during deployment, in contrast with deployments to Staging slot and swapping it with Production.

> **Comments:**
> **username_1**: If you have WEBSITE_LOCAL_CACHE_OPTION set to Always for the Production slot only but then deploy to staging using `az webapp deployment source config-zip` and swap with Production -- wouldn't you then run into the aforementioned incompatibility between WEBSITE_RUN_FROM_PACKAGE=1 and WEBSITE_LOCAL_CACHE_OPTION=Always as detailed in the links in the original post?   Basically, when these two configuration values are present, it causes the app to crash shortly after startup as it attempts to write to its local filesystem which is now readonly due to running from a zip package.  
> **username_0**: @username_1 In my environment I stopped using WEBSITE_RUN_FROM_PACKAGE=1 because it's incompatible with WEBSITE_LOCAL_CACHE_OPTION=Always . The point of WEBSITE_RUN_FROM_PACKAGE=1 in my case was avoiding file locks. Instead, I introduced App_Offline.htm to gracefully stop the staging slot before deploying to it. I hope my comment makes sense, if not, please let me know and I will elaborate on it.  

---

