v1.2.0

🔑 Added DI Keyed Services support (docs)

Since .NET 8 we now have native support for multiple services of the same type, identified by different names, thanks to the addition of so called keyed services.

The idea is basically that we can now register services not only by type but also by specifying the name, like this:

services.AddKeyedSingleton<MyService>("foo");
services.AddKeyedSingleton<MyService>("bar");

and later is possible to resolve it by both the type and a name.

Another way is to simply mark a constructor parameter or web action with the [FromKeyedServices] attribute, like this:

app.MapGet("/foo", ([FromKeyedServices("foo")] MyService myService) => myService.Whatever(123));
app.MapGet("/bar", ([FromKeyedServices("bar")] MyService myService) => myService.Whatever(123));

From now on, when registering a named cache, we can simply add AsKeyedServiceByCacheName() like this:

services.AddFusionCache("MyCache")
  .AsKeyedServiceByCacheName();

and later we'll be able to have the named cache both as usual:

app.MapGet("/foo", (IFusionCacheProvider cacheProvider) => {
  var cache = cacheProvider.GetCache("MyCache");
  cache.Set("key", 123);
});

and as a keyed service, like this:

app.MapGet("/foo", ([FromKeyedServices("MyCache")] IFusionCache cache) => {
  cache.Set("key", 123);
});

We can even use AsKeyedService(object? serviceKey) and specify a custom service key like for any other keyed service in .NET.

On top of being able to register FusionCache as a keyed service, we can even consume keyed services as FusionCache components, like memory cache, distributed cache, serializer, backplane, etc.

For more read at the official docs.

See here for the original issue.

⚡ Add PreferSyncSerialization option

It has been observed that in some situations async serialization and deserialization can be slower than the sync counterpart: this has nothing to do with FusionCache itself, but how serialization works in general.

So I added a new option called PreferSyncSerialization (default: false, fully backward compatible), that can allow the sync version to be preferred.

See here for the original issue.

🔭 Better OpenTelemetry traces for backplane notifications

Community user @imperugo noticed that when using the backplane with OpenTelemetry traces enabled, all the spans for the notifications incoming via the backplane were put under one single parent span, basically creating a single mega-span "containing" all the others.

Ideally, each span for each notification should be on their own, and now this is the case.

Also while I was at it I noticed another couple of things that, if added to the traces, could make the developer experience better.
In detail:

• include a tag with the source id (the InstanceId of the remote FusionCache instance)
• change the status of the trace in case of errors, like invalid notifications or similar
• add an event in case of, well, some event occurring during the activity

So yeah, I took this opportunity to make the overall experience better.

Finally, since backplane notifications can create a lot of background noise inside observability tools, I changed the default so that, even when there's a backplane setup, traces for backplane notifications are not enabled: to change this simply enable it at setup time.

See here for the original issue.

🐵 Add ChaosMemoryCache

Among all the chaos-related components already available, one to work with IMemoryCache was missing: not anymore.

✅ Better tests

Some more tests have been added, including better cross-platform snapshot tests.

📕 Docs

Updated some docs with the latest new things.