Alastair Crabtree

I have looked at your test code [from here](https://github.com/ArnaudB88/LazyCache/blob/140b446fd091eb989756325aad607e37836b232e/LazyCache.UnitTestsAspNet/HttpContextTests.cs). You cannot do dependency injection resolution (`_container.Resolve();`) inside the cached function `LongRunningDatabaseCallAsync` because that func does not run on the http...

It's not LazyCache starts a new thread, it is that because it is async the resumed task will be picked up by an availed thread from the pool you don't...

Mind if I close this issue now? Or still need anything?

Hi, and thanks. Do you mean sign the nuget package or just the dll/strong naming? See these docs for some background - http://blog.nuget.org/20150203/package-signing.html and https://msdn.microsoft.com/en-GB/library/xc31ft41%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

More thought food * https://github.com/NuGet/Home/wiki/Package-signing * https://docs.microsoft.com/en-us/nuget/create-packages/sign-a-package * https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Some more info on package signing that makes me think it's still not a great idea https://haacked.com/archive/2019/04/03/nuget-package-signing/

Hi thanks for this. The challenge with accepting this is that I imagine all operations against the cache will now take around twice as long because there are effectively 2...

I suspect the bug is because the immediate expiration stuff was never tested with sliding expiration. Looking at https://github.com/alastairtree/LazyCache/blob/master/LazyCache/Providers/MemoryCacheProvider.cs#L55 you can see it seems to cancel based on absolute expiration...

Just released a new version, may well fix this. Let us know how you get on? Install-Package LazyCache -Version 2.4.0

A PR with a failing unit test would help track this down if you are willing?