Suggestion: drop AspNetCore from name

[krispenner]

The distributed cache interface is not dependent to be run from within ASP.NET Core. We use it within a basic console applications running in k8s. To remove confusion for people, like myself, who would like to use your Firestore distributed cache implementation outside of ASP.NET Core, I suggest you drop the AspNetCore from the project and namespace in the next version.

You are not dependent on anything related to ASP.NET Core from Microsoft or other references.

using Microsoft.Extensions.Caching.Distributed;
using Microsoft.Extensions.Logging;

    <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="2.1.2" />
    <PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="2.1.1" />

[krispenner]

Is this maintained anymore? I see the only NuGet package is a pre-release from over a year ago. Are there any plans to officially release this?

[jskeet]

Thanks for the questions. We (the team) need to discuss this further.

The distributed cache package has far fewer downloads than the data protection packages, but it's entirely possible that that's due to a few continuous integration processes, for example. It's also possible that KMS isn't the most appropriate API for data protection now - Secret Manager may be more appropriate.

We'll talk about it and try to get the code in this repo out of its current limbo - but with vacations, it may be a few weeks before there are concrete decisions.

[jskeet]

Okay, we've now discussed this, and decided:

• We do want to support these, and get them released to beta and eventually GA
• We'll strongly consider the suggestion of renaming the distributed cache package
• We'll update all the actual ASP.NET Core dependencies to 3.1 (as the latest LTS version)
• We'll consult internally about whether we should be using KMS, SecretManager or both

We're not expecting to make any progress on this during August due to vacations, but I'm hopeful that we can get beta builds out by the end of September.

[krispenner]

Sounds awesome, thank you Jon! You can close this if you wish unless you want to keep it open for tracking this.

[jskeet]

Nah, we'll keep it open until we've decided on the name, at least.

[chrisbbe]

Any progress on "We'll update all the actual ASP.NET Core dependencies to 3.1 (as the latest LTS version)"? Or are PRs welcome?

[jskeet]

No, we haven't had any time to look at this yet. Yes, PRs would be welcome.

[jskeet]

Okay, we now have more of a plan - although nothing will actually happen for a little while:

• We'll think about the data protection libraries again from scratch:
  • All of this will happen in https://github.com/googleapis/google-cloud-dotnet where most of the rest of our libraries live
  • We'll potentially move to SecretManager instead of KMS
  • We'll update dependencies to newer LTS ones (maybe 3.1, maybe straight to 6.0)
  • We'll remove the AspNetCore part from the name
• We won't migrate the Firestore distributed cache package, as that doesn't seem to have nearly as much usage
• We won't migrate the templates (which are very out-of-date now)
• We'll archive this repository

No promises around timelines for this, but I wouldn't expect to see anything before Q2 of 2022. Sorry that this is taking so long - it's relatively low priority with lots of other high priority work happening at the same time. We do want to get there eventually though, with the "right" libraries instead of just releasing what we've already got.

[memark]

Thanks for the update, looking forward to the coming work!

[samcarton]

Was there ever an update here? We're looking into what data protection libraries are available for GCP, and it doesn't look like there's any mention of them over in https://github.com/googleapis/google-cloud-dotnet

[jskeet]

Sorry for this taking so long. We do still have it on our backlog... the rough plan is:

• Archive this repository
• Work out what customers should do, probably using Secret Manager
• Either provide sample code in the Secret Manager library documentation, or create a new library if it's fiddly enough to merit that

I doubt that we'll be releasing non-alpha versions of these packages though, if that's any help in deciding on your next step.

I'd suggest looking at Google.Cloud.SecretManager.V1 as the starting point for your code, assuming that what you want is to store secrets.

[samcarton]

thanks for that ultra-quick reply @jskeet . Yes we are looking at options for secret management, and stumbled upon the ProtectKeysWithGoogleKms extension in here that looked very promising. It would be nice to have a drop-in replacement that works in GCP, as the options in the MS docs only mention azure keyvault, windows-specific things, or managing your own x.509 cert.