Port System.Runtime.Caching to .NET Core

[timheuer]

In attempting to convert some libs to .NET Core for use in where .NET Core is growing (e.g., AWS Lambdas), I'm blocked on System.Runtime.Caching components or an equivalent.

[karelz]

This is the first request for this API.
Do you know which libraries need which classes in the System.Runtime.Caching namespace?

cc: @weshaggard @danmosemsft - any comments on our usage data?

[timheuer]

The one I'm working with is https://github.com/AreYouFreeBusy/AlexaSkillsKit.NET/blob/ef7f2259a74f052c0980c200fe0caf891e4d4092/AlexaSkillsKit.Lib/Authentication/SpeechletRequestSignatureVerifier.cs

[tarekgh]

from the reference code I am seeing the used classes are:

    CacheItemPolicy
    MemoryCache

and the enum

    CacheItemPriority

[karelz]

Which libraries need them and why? (disclaimer: I have 0 knowledge about the APIs)

[tarekgh]

The code consuming the classes CacheItemPolicy and MemoryCache is the open source library AlexaSkillsKit.dll in https://github.com/AreYouFreeBusy/AlexaSkillsKit.NET/tree/ef7f2259a74f052c0980c200fe0caf891e4d4092/AlexaSkillsKit.Lib

System.Runtime.Caching namespace is defined in the full framework in a library called System.Runtime.Caching.dll and the whole library never get ported to net core

[danmoseley]

@karelz usage is about 2% based on nuget and apiport telemetry : https://apisof.net/catalog/System.Runtime.Caching

[madelson]

My company would need System.Runtime.Caching to port our apps to .NET core as well.

[tarekgh]

@weshaggard could you please advise regarding this namespace porting?

[weshaggard]

System.Runtime.Cachine is the correct namespace. These APIs have transitionally been used for web scenarios and the ASP.NET team has traditionally owned them.

[karelz]

Should we ask ASP.NET team to ship them in their libraries instead of CoreFX then?

[davidfowl]

We replaced System.Runtime.Caching with http://github.com/aspnet/Caching but that might be unrelated to this porting exercise since this is about bringing back older APIs.

[karelz]

In that case I would be curious how difficult is it for apps to migrate to the new API? @timheuer @madelson can you check it out please?
If it is not that bad, could we get away with not porting the old namespace?

[madelson]

@karelz looking at the new APIs porting seems possible but is not super direct. Our use of the existing APIs is woven through a number of internal libraries which would each need to take on a breaking change as well as a number of new dependencies to start using the aspnet APIs.

Two additional potential concerns I have about switching to the new aspnet APIs:

• We use the existing MemoryCache in both web and non-web scenarios; since this is under the ASP.NET umbrella is there risk that future development might compromise the non-web use case in favor of the web one?
• It looks like the new APIs rely heavily on various interfaces which are problematic from a backwards-compatibility perspective. If later releases to the new caching packages will break compatibility, that seems like it could cause issues for us as we try to keep our internal libraries compatible with various internal consumers. I'm unsure how likely this is.

From our perspective, System.Runtime.Caching would be released as its own NuGet package to aid in porting while not cluttering the core framework.

That said, I can understand if this doesn't get prioritized given that there is a reasonable alternative available.

[karelz]

Disclaimer: I don't have any deeper knowledge of the caching APIs, so please be patient with me if my answers seem irrelevant or obvious for person who knows the APIs.

We use the existing MemoryCache in both web and non-web scenarios; since this is under the ASP.NET umbrella is there risk that future development might compromise the non-web use case in favor of the web one?

The original MemoryCache was also developed mainly for ASP.NET scenario (technically by ASP.NET team). From that perspective the risk in non-web use cases is the same for both - the old and new APIs. The old APIs have additional the downside/risk of not being actively maintained/developed at all.

It looks like the new APIs rely heavily on various interfaces which are problematic from a backwards-compatibility perspective. If later releases to the new caching packages will break compatibility, that seems like it could cause issues for us as we try to keep our internal libraries compatible with various internal consumers. I'm unsure how likely this is.

The whole .NET platform (incl. .NET Core) takes compatibility very seriously. I don't think there is any reason to be more worried about new ASP.NET APIs breaking compat than to be worried about compat breaking in general (or if we ported the old APIs being afraid of compat changes in that code).

System.Runtime.Caching would be released as its own NuGet package to aid in porting while not cluttering the core framework.
That said, I can understand if this doesn't get prioritized given that there is a reasonable alternative available.

Helping apps migrate to .NET Core is one of the key values we're focusing on. We prioritize the most popular APIs over the rarely used APIs. However, we do not plan to chase the tail -- if some API is less used and we do not believe it is must-have and there are not many customers who truly need it, we do not plan to bring it over ever.
It saves us cost to port the code, it also saves us (non-trivial) ongoing maintenance cost - bug fixes, questions, PR reviews, overall expertise on the API, incl. assessing compat impact of changes, and forming an opinion how evolution of the API should look like. It also helps devs to avoid using the "compat" API by accident (if it is not there, it won't be used more).

Given that we have "only" 2 asks so far for this API and that there is an alternative API, we do not plan to invest into the API. However, if in the future we see more interest from developers, we may change our view point / prioritization.

[madelson]

@karelz thanks that all makes sense to me. I mostly wanted to get in my "vote" for porting this, with full understanding that it might not make sense to do so now or ever.

[karelz]

Great. Vote is noted, thank you! (BTW: Upvoting the original post would be best - GitHub can sort by that ;-))

Just to reiterate what I said above: We will happily reprioritize / change our view point in future if we see more interest in the library from more customers.

[mjsabby]

I suggest that we add this since it doesn't seem that hard to get to run on .NET Core. @weshaggard if there aren't any objections, we can put this up for grabs.

I'd like to note that our official docs do say it can be used outside of ASP.NET, in fact if I remember correctly it was moved out of System.Web for such scenarios.
https://msdn.microsoft.com/en-us/library/system.runtime.caching(v=vs.110).aspx

[weshaggard]

@weshaggard if there aren't any objections, we can put this up for grabs.

I don't have any objections to adding it if we can make it work reasonably as a standalone component.

[MichaCo]

@karelz @davidfowl I vote for that System.Runtime.Caching is NOT needed in the "new" world as we have all kinds of other alternatives now. And it would be kinda confusing to have to decide between that cache and Microsoft.Extensions.Caching.MemoryCache as they probably will be doing 99% exactly the same thing.

Porting existing apps might be an issue, but if you use a caching abstraction and DI, you'll find that process being very simple, just change it in one place...

There are also libraries which do that abstraction for you, like https://github.com/MichaCo/CacheManager which supports the old RuntimeCaching and the new stuff.

[karelz]

Thanks @MichaCo for your view point.
I am curious if the above information changes community members' opinion? (please upvote / downvote the post above accordingly, or reply)

[NickCraver]

As a library author, I'd like to see it in. We have many providers for various bits of storage, System.Runtime.Caching being one of them. Remember, many ported to this off of HttpRuntime.Cache already. Telling a user that they need to do X on full and Y on netstandard isn't friendly, and our choices boil down to:

• Take an abstraction dependency
• Have 1 provider built on each (user pain)
• Everyone writes pretty much the same abstraction/implementation split, and hopefully get the caveats right

This is a relatively simple structure, and to reduce pain all around (including porting pain), it should make the trip.

[akoeplinger]

I agree it should be ported. We replaced Mono's implementation with the one from referencesource ~2 years ago but had to reimplement internal classes like UsageEntryRef, CacheUsage, ExpiresEntryRef and CacheExpires because they are missing from referencesource for some reason so it'd be great to get rid of that code 😄

[NickCraver]

It's worth noting that what @akoeplinger mentions makes up-for-grabs a bit interesting...since we don't actually have the source for that. I have no idea why they were never in reference source, it's also annoyed us for the better part of a decade when debugging :)

[karelz]

OK, we seem to have quite a few folks interested in this.
@akoeplinger would it be feasible to use Mono implementation and tests for the port? Or do you think we should take Desktop sources? cc @marek-safar

@NickCraver @akoeplinger can you please file a new bug to track missing code on ReferenceSource?
@richlander any reason why internal classes are missing in https://github.com/Microsoft/referencesource/tree/master/System.Runtime.Caching/System/Caching (UsageEntryRef, CacheUsage, ExpiresEntryRef, CacheExpires)? Same here: https://referencesource.microsoft.com/#System.Runtime.Caching,namespaces

[mjsabby]

Let's stick to desktop, I did a cursory glance a while back and it was just a copy paste dump that we'd need to do.

[karelz]

@mjsabby did you look at tests?
Do you plan to help with the port?

[marek-safar]

@karelz our code is referencesource based modulo missing bits. We have been promised publishing of missing internal types on several occasions during past year(s) but still no action.

[karelz]

@marek-safar that's a good data point - who did you talk with in the past? I'll be happy to push on it.
Also, do you have a full list of missing things?

[karelz]

I have created issue to track missing ReferenceSource - dotnet/corefx#16441
Let's focus on the port in this issue ...

[CZEMacLeod]

Our codebase has a lot of references to System.Runtime.Caching, including System.Runtime.Caching.ChangeMonitor. Any progress on this item as this is one of our major sticking points with migrating to NetStandard

[richlander]

I have also used this type in my apps. I upvoted.

[hubert-associates]

Hi, we are looking at this interface in the API-throttling context as shown here on stackexchange

Or is there a viable alternative cache in this context?

Thanks

[jj09]

+1

[StingyJack]

I guess this one (that I need) is one of the 43 that are in netfx461 but not in netstandard20?

https://github.com/dotnet/standard/blob/master/docs/netstandard-20/README.md#net-framework-461-supporting-net-standard-20

[karelz]

@StingyJack no, the 43 APIs in the other direction - those are APIs which ARE in netstandard20, but not in netfx461.
There are plenty of APIs which are in netfx461, but not in netstandard20/netcore20. This is one of them.

[StingyJack]

@karelz - had to read it a few times, but I see what you mean.

Is there a list of those diffs? I remember seeing something similar circa .net core10 preview that listed namespaces that weren't yet migrated.

[karelz]

I think @weshaggard had a diff between platforms.
Otherwise you can use ApiPort on your applications and libraries: https://github.com/Microsoft/dotnet-apiport

[greenbergjosh]

+1
I couldn't determine from the comments above if it was decided that this would be done or not. Was there a decision?

[karelz]

@greenbergjosh no decision or timeline yet.
We have active internal thread about it though, so it is not forgotten.

[danmoseley]

PR dotnet/corefx#25169

[Petermarcu]

@danmosemsft whats left on this one?

[danmoseley]

This is done except minor issues dotnet/corefx#26171 and possible Unix port dotnet/corefx#26172

It also needs to go up on Nuget with S.R.Caching added - @safern is doing this now.

[shvez]

any news about this? when it is planned to release this nuget package?

[safern]

any news about this? when it is planned to release this nuget package?

This is done and complete. The package is available on Nuget:

https://www.nuget.org/packages/System.Runtime.Caching/

[shvez]

Thank you. good news

[stpriyanka]

this https://www.nuget.org/packages/System.Runtime.Caching/ solved for me!