Issue with enableShadowCopy and shared shadowCopyDirectory in Multi-Environment Deployment

[Vasilievski]

While deploying an ASP.NET Core application, I encountered file locking issues. I discovered the enableShadowCopy parameter, which seemed to address these concerns.

However, the documentation around this feature is lacking, with no detailed information on its functionality, prerequisites, etc.

The reference I followed is here.

Configuration:

I have an application deployed across multiple pools on the same machine, simulating multi-environment deployment. All application folders are structured at the same level. I've set up shadow copying as shown in the documentation:

  <handlerSettings>
    <handlerSetting name="enableShadowCopy" value="true" />
    <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
  </handlerSettings>

There's no indication in the documentation that the shadowCopyDirectory should be unique for each app, so I used a shared directory.

Issues Encountered:

Soon after, we started observing problems related to missing DLLs and received errors like:

Application '/LM/W3SVC/6/ROOT/Api' with physical root 'C:\Api\' failed to load coreclr. Exception message:
File changed between copy and start of application, restarting.

Upon investigation, I found a concerning code segment in the ASP.NET Core source. This segment deletes ALL subdirectories within the user-defined shadowCopyDirectory, which is risky. In our deployment, it led to shadow copy directories unintentionally deleting one another.

Here's the concerning code:
ASP.NET Core Source.

Please consider revising this behavior or, at a minimum, provide clear documentation on the potential risks and the necessity of unique shadow copy directories for each application.

[adityamandaleeka]

Thanks @Vasilievski, yea we should at least update the docs here.

[RickStrahl]

Moved from #55216

I guess the question is: Is this by design? It seems like ACNM should have some way to figure which app it's working with and only delete the app it's working on.

The workaround of using specific directories is not a big deal if documented. but totally not obvious given that new folders are created for each app.

It seems to me this behavior has changed, because I've been running multiple shadow copied apps in a single SC folder for close to 2 years without issues and it started becoming a problem only recently when I updated to 8.0.4.

The problem resolved for me when I set up my shadow copy folders like this:

../ShadowCopyDirectories/WebStore
../ShadowCopyDirectories/LicensingService
../ShadowCopyDirectories/WebSurgeServer

[RickStrahl]

I am however still wondering why heck using a single Shadow Copy folder without cleanShadowCopyDirectory failed with folder check corruption. That had been working for 2 years and now started failing.