Version 3.3.0

Serialization updates

Thanks to @cole-brown for doing the leg work on updating filecache. Notes from his PR:

BinaryFormatter is a security issue in .NET 5.0 - this replaces it in most places.

https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide

BinaryFormatter is replaced with BinaryReader/BinaryWriter for:

sysfiles
policies
ReadFile w/ PayloadMode.RawBytes
WriteFile w/ PayloadMode.RawBytes
Cache files that use BinaryReader/BinaryWriter have a "magic" header number that is checked for in order to make the transition from 3.2.0 to this patch without needing to delete your file cache. The old files will just fail the new header check and the sysfile/policy/etc will continue on as if it were a failed read/missing file.

BinaryFormatter remains for:

ReadFile w/ PayloadMode.Serialize
WriteFile w/ PayloadMode.Serialize
Those would need to be serialized some other way that wasn't needed for our use case.

You could look into adding ZeroFormatter as a dependency:
https://neuecc.medium.com/zeroformatter-fastest-c-serializer-and-infinitely-fast-deserializer-for-net-88e752803fe9
https://github.com/neuecc/ZeroFormatter/
https://www.nuget.org/packages/ZeroFormatter
Or possibly using an XML/JSON formatter instead:
https://docs.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide#preferred-alternatives
This pull request partially addresses: #49

Version 3.2.0

Tagged release containing Apache license.

Version 3.2.0

• Removed support for < .NET 4.5
• Fixed bug #42 by calling ShouldClean after CacheManger construction
• Addresses Issue #35 by using xxHash to generate stable hashes

Version 3.1.0

• Updated assembly to support .Net Standard 2.1
• Updated constructor to better support config options (requires minor version bump)

First 3.x marked as non-prerelease as 3.x has been available for more than a year and nobody seems to have complained that much.

Version 3.0.1

A build of version 3.0.0 that actually compiles.

Version 3.0.0

New in Version 3

Version 3 allows for the building of custom caching schemes. The first release contains
two caching schemes, Basic and Hashed.

The Basic scheme is the tried-and-true scheme employed in all prior versions of FC. When
using the Basic scheme, file names are taken from the cache key. For example, executing
the command simpleCache["foo"] = foo; will create a foo.dat file
to store the value of foo. This plaintext conversion can be convenient when debugging
or when accessing FC cache values from outside of FC. However, it also has the
downside of not supporting cache key names that cannot be used in file names (e.g. /).

Rather than using key names as file names, the Hashed scheme, introduced in Version 3.0,
uses hashed representations of key names using the built-in .NET function
GetHashCode(). This function produces a numeric representation of each key that is
guaranteed to produce a valid file name. However, the downside of this approach is
that GetHashCode() is not guaranteed to produce a unique key. Therefore, FC must
account for collisions when using the Hashed scheme. This slight overhead is likely to
correspond in slighly higher cache retrieval times.

For now, the default caching scheme is set to Basic in order to maintain compatibility with
prior releases. Furthermore, while the Hashed scheme passes all unit tests, it should
be treated as experimental until additional field testing has been conducted.

Version 2.2.0

PR #24 now allows FileCache to store raw bytes using byte[] or Streams. This also means that FileCache supports scatter/gather IO.

Version 2.1.4

Added another fix to address issue #18.

Version 2.1.3

• Fixed an issue in which theoretical race conditions would create unexpected results (issue #19).
• Fixed an issue in which accessing the same file cache across multiple threads would cause a runtime exception (issue #18).

Version 2.1.2

This version requires non-alpha versions of the .NET Standard library and can now be labeled as non-alpha in nuget.