Deployment and testing "gocha's"

When you are working on an application you often want to: 1) run the application locally and 2) run unit tests locally. This document covers these two needs when you are using the Net.DistributedFileStoreCache library. In summary:

1. Running an application that uses a FileStore cache locally works fine in Debug mode, but if run in Release mode it will create a json cache file which it will a json cache file with the same as your production system which, by default, WILL OVERWRITE YOUR PRODUCTION json cache file.
2. If you need to test code that uses the FileStore cache, then you MUST to create a Stub implementation of the FileStore cache.

The next two sections cover these two issues in more detail.

Making sure your production FileStore cache isn't overwritten on deployment

If you have registered the FileStore cache correctly, then when you run in Debug mode a json cache file containing the string "Development" will be used which is fine. But if you build/run your application in Release then you create a json cache file with the same name as your production system, and that json cache file will, by default, and when you deploy your application production system WILL OVERWRITE YOUR PRODUCTION json cache file. This means

1. Your current production cache data is lost!
2. The cache data is replaced by your local cache data

For these reasons I strongly suggest you set the Production json cache file (and other deployable versions, e.g. Staging) property Copy to Output Directory to Do not copy. You can do this either by:

• Via VS's properties of a file.
• Or by adding the code below to your ASP.NET Core .csproj file

  <ItemGroup>
    <Content Update="DistributedCacheFile.Production.json">
      <CopyToOutputDirectory>Never</CopyToOutputDirectory>
    </Content>
  </ItemGroup> 

NOTE: The default name of the Production json cache file is FileStoreCacheFile.Production.json.

Test your application that uses FileStore cache

The FileStore cache doesn't work when running tests in parallel, e.g. using xUnit. This is because the FileStore cache uses a hidden static cache. The answer to this problem is to create a Stub implementation of the interface for the FileStore cache version you want to use. Its pretty easy to create a Stub, and I provide an example in the repo called StubFileStoreCacheString.

NOTE: It you really want to use the real FileStore cache in your unit testing then look at the tests within the Test.UnitTests directory. Note the [Collection("Sequential")] at the top of tests that have to run in series.