Google-cloud-dotnet: Upgrade client libraries to gRPC C# 2.x and new async sequences

Created on 19 Sep 2019  路  31Comments  路  Source: googleapis/google-cloud-dotnet

I know there's a plan to switch all the API client libraries to Grpc C# 2.x, but I didn't see a tracking issue filed, so I'm filing one.

Please provide the ETA of making the switch (if already known).

Context: https://github.com/grpc/proposal/blob/master/L57-csharp-new-major-version.md

feature request

Most helpful comment

Big news: we've now released GAX 3.0.0-beta01. This week I'll be starting to release all the individual APIs.

All 31 comments

"End of 2019" is the closest we've got to an ETA at this point.

This maybe is a bit of a stupid question @jskeet , so excuse me beforehand.
But does that mean people wanting to use the new gRPC features in Kestrel, however they also use libraries like PubSub and Google Logging, can NOT do so since you are depending on 1.2.x of gRPC Core library?

I am asking because I am trying to update some of our micro services to .NET Core 3 and naturally I add Grpc.AspNetCore 2.23.2. This in turn makes my PubSub getting stuck on creating a subscription, due to the fact that the library depend on Grpc.Core.Api 1.22.1, while Grpc.AspNetCore 2.23.2 updates that version to Grpc.Core.Api 2.23.0.

Is this correct?

@ivan-penchev: Yes, that's correct, unfortunately. This is effectively a limitation of .NET versioning :( I don't know of any workaround for it at the moment. We're really hoping to do the upgrade in Q4 though - I'm actively planning it.

@jskeet because for most users, the difference between Grpc.Core.Api 1.x and 2.x is a binary-only breakage which can be fixed with just a rebuild, how hard would it be for users that need to use gRPC C# 2.x (or what to try with grpc-dotnet) to build the client libraries from sources themselves?

Also, we (the gRPC team) do have "dev" nuget channel where we could potentially push an experimental build of the client libraries' nugets built against Grpc.Core.Api 2.x so that people could at least try it out.

@jtattermusch: Practically infeasible. There's a lot more to it, with lots of changes in GAX. We can definitely think about using the Dev channel for alphas though - thanks for that thought.

@jskeet do you mean there's a lot of changes in GAX just to be able to re-build against Grpc.Core 2.x (which is somewhat surprising to me, but good to know if that's the case) or there's a lot of changes in GAX associated with the future 2.x release of client libraries (which I totally get).

Well, gRPC isn't the only use of System.Interactive.Async in GAX. We need to move completely to Microsoft.Bcl.AsyncInterfaces. Just recompiling against gRPC 2.x without doing that could lead to weird errors I suspect. I don't think it's worth spending a lot of time investigating temporary solutions - I'd rather put the effort into getting the final solution done right and quickly.

There are also changes to be made in the generated code IIRC, which would either need to be done manually per library, or be done in the generator, which isn't something we'd want to ask users to do. (There's an awful lot of infrastructure involved here.)

We now have a public plan for this: https://googleapis.github.io/google-cloud-dotnet/docs/major-version.html

It's a pretty conservative plan (with beta libraries in January 2020 and GA libraries in February 2020). I hope we'll be able to overachieve on that and bring the dates in, but I didn't want to overpromise in the planning doc.

@ivan-penchev I have the same problem on a small project and currently solved it using code-base tag. It allows to add location for different versions of the same dll.

Temporary solution:

  • separate sub projects inside the solution based on the gRPC version used
  • a master project that has references to the projects needed. The master project needs the configuration presented earlier to allow multiple versions of the same dll.

More detailed example here.

This might be worth at least updating the documentation about this limitation for now. It basically means without the workaround, if you make a new gRPC project in VS (based on Grpc.AspNetCore), none of the GCloud libraries which depend on gRPC will function properly (blocking on every async call)

Good to find the cause though :) thanks a lot both!

@SKLn-Rad: We tried to make it even fail to build using dependency restrictions, but I suspect that doesn't quite work as we depend directly on Grpc.Core.

Could you suggest where it would be best to document this? We do have a FAQ entry around EntryPointNotFoundException (which is what I'd expect to see rather than a blocking async call) but I suspect even that isn't discoverable enough. If we added a prominent notice to the README.md in this repo, would you have found that?

Probably not, it took me a while to dig to find this!
Its weird as I seem to be able to use the services (in my case Firestore) as long as I don't await them. The data is there...

It just never returns so I expected it might be down to how the different versions handle unary requests but I might be very wrong!

I suspect by the time there are incompatible major versions, there are any number of ways in which it could break :)

If you can think of a good place to put a documentation note, I'm happy to do so - otherwise, I'll focus on removing the blockage entirely ;)

Ah thanks for everyone's hard work on all of this, especially over the holiday period. Just to put it out, we likely would have seen or liked a notice on the readme detailing this issue, but we eventually found this issue and the public plan @jskeet linked above, so no big deal. If it is expected to take a couple of weeks before a beta build gets out, it might still be worth putting a notice on the readme still.
Either way, good to know it is being sorted :)

@LiamMorrow: Thanks; I've added a note to the README.md now. Whether or not folks find it is a different matter, but it definitely doesn't hurt!

I have been trying to follow the progress on this, by checking the commit histories in the repos, and looking for beta releases on nuget. However it is a bit difficult to grasp what is happening exactly.

@jskeet considering it's last week of January, and the public plan has not been recently updated, can we have a brief statement of how are things progressing? Are we still expecting public betas this month? GA hopefully by end of February?

@ivan-penchev: Beta is likely to be early February - by the 10th, I should think. GA by end of February itself is still achievable if we don't run into problems, but we'll see.

The main blockers are:

  • Migrating the final APIs onto the microgenerator (prerequisite for this work)
  • Making sure we've done everything we want to for GAX, where things like this PR around gRPC portabilty are important but tricky.

Is the alpha version available yet?

@nkigen: Not as NuGet packages, no. You can build GAX yourself from source, for sure - that's what we're doing when developing the next-major-version branch here. Since coming up with the plan, we've reflected that it probably isn't wise to release alphas - but betas are definitely on the way. I need to update the plan to indicate what's going on - I'll try to do that today.

We're currently blocked on a protobuf issue, hoping for a new release of that this week. Ideally we'd also wait until all APIs can be converted to microgenerators - we're now down to just three (after #4246 has been merged) and if necessary I think we can start releasing betas without those. I'm currently hoping to release GAX 3.0.0-beta01 next Monday and then spend the rest of the week rolling out beta releases of all the APIs. (I'll be putting together release notes and breaking changes for each release, which is why it be pretty resource-intensive.)

Sorry that this is taking so long, folks - please believe me when I say it's at least as frustrating for me as it is for you!

Big news: we've now released GAX 3.0.0-beta01. This week I'll be starting to release all the individual APIs.

We've now released new beta versions of all APIs except AutoML (where we're waiting on more annotations) and BigQuery/Storage (where we're doing some feature work before releasing).
We'd love to get feedback on whether the betas work for you. Best to catch any problems early!

What is the scope of the BigQuery feature work, just trying to get a feel for an ETA for BigQuery.. Thanks

Incidentally our project uses Pub/Sub, Storage and BigQuery. In the mean time, we have built local packages off the betas and worked from them. Currently running in our preprod envs and haven't had any issues. Was good to remove the workaround code we've written. Thanks all who have been working to get these out.

@sitepodmatt: I'll see if I can get a BigQuery (and Storage) beta out today. There will be some more breaking changes in later betas I suspect, but at least everything will be on GAX v3. And the breaking changes in Storage and BigQuery will be reasonably small.

@LiamMorrow: Are you using PubSub, Storage and BigQuery in the same process? I'd actually be surprised if that works at the moment due to the breaking changes in GAX (and the way .NET versioning works), but it should get better when I've got Storage and BigQuery betas out.

Yeah we are, but we created a local nuget package of BigQuery and Storage using the head of master in this repo. So they are using GAX 3.0 as well. Previously we were running bigquery in an aspnet core 3 with GRPC using the old version, which as long as we steered clear of IAsyncEnumerable, worked with no problems. Pub/Sub was a different kettle of fish though, had to do some creative assembly resolution there, but since the beta we have removed that.

@LiamMorrow: Ah, right. Thanks for the explanation - and I'm sorry that this process has caused so much hassle. I'll ping this issue again when I've done BigQuery and Storage releases so you can revert to "stock" versions.

No dramas, it's understandable given the scope of these libraries.

Google.Cloud.BigQuery.V2 version 2.0.0-beta01 and Google.Cloud.Storage.V1 version 3.0.0-beta01 have now been released.

Ah you legends. Will plug em in tomorrow and log if there鈥檚 any weirdness about

GAX 3.0.0 is now released, and there are client libraries depending on that GA release for all APIs. Most are GA client libraries (where the API is also GA) except for a few cases where we believe there's at least a strong possibility of wanting another breaking change soon. We hope to release all of those as GA "reasonably soon".

Closing this issue now - hooray. (Will tidy up documentation around all of this over time.)

Was this page helpful?
0 / 5 - 0 ratings