Developers can call gRPC services from .NET Framework

[JamesNK]

Problem:

MS guidance is to migrate WCF apps to gRPC where possible when moving from .NET Framework to .NET Core. Migrating multiple inter-connected apps is a big task and is difficult to do all at once. There is a transitionary period where older .NET Framework apps will hang around and need to use newer gRPC services. There needs to be a good gRPC client solution on .NET Framework.

Our new gRPC client, Grpc.Net.Client, supports .NET Core 3 and later. .NET Framework apps must use Grpc.Core on .NET Framework. Grpc.Core is functional, but its TLS stack is problematic because it doesn't integrate with Windows cert store and breaks guidance. This blocks some customers from calling gRPC from the .NET Framework, and complicates their migration from .NET Framework to .NET Core/.NET 5.

Solution:

Grpc.Net.Client could be updated to support .NET Framework by using WinHttpHandler as its HTTP stack. WinHttp doesn't have the TLS issues that Grpc.Core does and would unblock customers.

For Grpc.Net.Client to support .NET Framework, WinHttpHandler will need to be updated to support HTTP/2 trailing headers, and to verify that it supports bidirectional streaming:

• WinHttpHandler HTTP/2 trailing headers - WinHttpHandler HTTP/2 trailing headers runtime#44778
• Add .NET Standard 2.0 support to Grpc.Net.Client - Add .NET Standard 2.0 support for Grpc.Net.Client grpc/grpc-dotnet#1176

Future:

• WinHttpHandler - HTTP/2 bidirectional streaming - WinHttpHandler - HTTP/2 bidirectional streaming runtime#44784 ... 2021/1/6 status: Not supported by WinHttp yet

[danmoseley]

Making sure this is on @karelz radar.

[danmoseley]

@karelz is discussing and working on costing.

[karelz]

@danmosemsft I will remove the Team:Libraries label, as it is now present on the one depencency. This issue should track the end-to-end User Story, which will require changes in gRPC as well (to be added above by @JamesNK I assume).

[danmoseley]

(to be added above by @JamesNK I assume).

@JamesNK are you planning to add this? We presumably need to establish that either all dependencies are committed, or none.

[JamesNK]

Added grpc/grpc-dotnet#1176. Is it ok that it is not in a dotnet repo? I can create an issue in dotnet/aspnetcore if it is a problem.

PR to support .NET standard 2.0 is already mostly done - grpc/grpc-dotnet#1118. I wanted it to verify that WinHttp changes actually work end-to-end. Interop tests show that they do 🍰

[danmoseley]

@JamesNK it's probably a good idea to make a proxy issue in aspnetcore so it shows up in themesof.net.

[JamesNK]

The grpc/grpc-dotnet issue shows up on the website.

[danmoseley]

what wizardry is this? I guess we query that repo too. Great.

[shirhatti]

@karelz @JamesNK Based on our conversation today supporting unary + server streaming calls with WinHttpHandler will happen in 6.0. As such I'm marking this as P1.

[karelz]

@shirhatti I am a bit puzzled. You told us the priority is P2. Yes, we plan to do it, but that should be orthogonal to priority. Shouldn't priority be based on scenario importance relative to other scenarios? That way it can be effectively used in future if plans change, more things are discovered, or higher priorities come in ...

[karelz]

@shirhatti @JamesNK ping?

[JamesNK]

Last I heard it was P2 but I'm not involved in meetings where this gets decided 🤷‍♂️

[shirhatti]

Oops. I just accidentally marked this as P1 😢

[yezilife]

We would love to see this as P1 if not P0 : )

[takekazuomi]

Current Grpc.Net.Client .NET Framework support is limited to Windows 10 Build 19622 or later. This is very strict and we can't use Grpc.Net.Client with App Service and .NET Framework. Will the Build restrictions be removed?

[JamesNK]

The short answer is no, a minimum version of Windows will always be required.

The long answer is gRPC requires HTTP/2. .NET Framework doesn't have built-in support for HTTP/2. WinHTTP, a HTTP client build into Windows, provides HTTP/2 for Grpc.Net.Client on .NET Framework. Features needed to be added to WinHTTP and they are only available on newer versions of Windows.

[takekazuomi]

It's painful that grpc-dotnet can't be used with App Service. For the time being, I use Grpc.Core for the .NET Framework. I expect the App Service Windows OS to be updated before Grpc.Core is deprecated.

[Bonuspunkt]

a minimum version of Windows will always be required

which version of Windows Server is required?

[karelz]

@JamesNK all work items seem to be addressed now. Should we close it as done?

[JamesNK]

DONE

[schhwork]

Pardon my ignorance here but i'm actually about to go insane trying to work out what this Windows 10 Build 19622 actually is, when it was released, was it even released, if so when. Any build history information like here:

https://docs.microsoft.com/en-us/windows/release-health/release-information

have no mention of this build number anywhere, and the only build number that looks like it follows this is at 19044 for the 21H2 version. I'm confused to say the least.

I would just like to know if implementing the current Grpc.Net.Client in my .NET Framework clients is something i should do or if i'm better off just sticking to Grpc.Core for now. Any clarification on this would be greatly appreciated.

[JamesNK]

Supported platforms are discussed here: https://docs.microsoft.com/en-us/aspnet/core/grpc/supported-platforms?view=aspnetcore-5.0#net-grpc-client-requirements

The important piece of information you are missing is that an Insider build might be required: https://insider.windows.com/

I believe the Win10 insider builds that support this have been replaced by Win11.

[schhwork]

Thank you for the swift reply, i guess that mean i'm sticking to Grpc.Core for now.

[alberto-chiesa]

First of all, thanks @JamesNK for raising this point.

I have a major concern, however: .NET Framework is still going to be a requirement in a lot of enterprise environments for a long time (at least, relatively to the pace the .NET versions are moving currently), and OS version requirements should also be taken into account.

AFAICT, the only way we are going to have anything gRPC related working in Win Server 2016 is going with .Net Framework + Grpc.Core. Am I correct?

If so, this means that Grpc.Core must "stay alive" at least for the lifetime of Win 2016 (which is 2022, or 2027 for the extended lifetime support), and possibly Win Server 2019, if it's true that gRPC is "the way forward".

I think the upgrade path for an enterprise application (think WCF + .Net Framework + Win Server 2016) is at the moment sketchy.

I would like to go to gRPC+.NET 5 in just one step, but that is not going to work: it's too much work in one step.

I would like to upgrade to gRPC while still in .NET Framework, and then get away from WCF with .NET Core 3 or .NET 5.
The planned deprecation of Grpc.Core is a frozen shower for this kind of plan: I don't want to base my migration plans on a discontinued library.

I really think we should keep Grpc.Core alive for longer, even if I'm the first that would prefer using Grpc.Net.Client everywhere.

[srini85]

I am also keen to know what is the minimum version of windows server required here.

[mnye]

As per https://docs.microsoft.com/en-gb/aspnet/core/grpc/netstandard?view=aspnetcore-5.0 I think this version of windows is not a general release (yet) but I'm still not sure how to opt-in to it. I just fully updated my workstation and WinHttpHandler still is not working for me, so for me it unfortunately isn't a solution for .NET Framework at the moment.

[Jascen]

Just noting for others that as of Win10 21H2 (build 19044.1415), bidirectional streaming is still not available.

The tests are tracking a build version that bidirectional streaming may be available in (10.0.22357.0 at the time of writing this).

Adding my experience in here in case it helps anyone else find this:

• My client called ResponseStream.MoveNext() and the Server logged (Grpc.AspNetCore.Server.ServerCallHandler) Request protocol of '"HTTP/1.1"' is not supported.
• This test indicates If WinHTTP doesn't support streaming a request without a length then it will fallback to HTTP/1.1.