Future support of .NET 4.8 on GRPC Server side

[Tom Teag]

It was announced that the Grpc.Core package will be phased out. Is there any other possibility to run a gRPC Server on the full .NET Framework (4.8) than using the Grpc.Core package?

[Jan Tattermusch]

Unfortunately, no. For running grpc-dotnet, you need to be on the ASP.NET Core stack, i.e. on .NET Core 3+ (or even .NET Core 2+ has just went out of support a few days ago).

As described in https://grpc.io/blog/grpc-csharp-future/, once Grpc.Core is deprecated, all the users will be expected to migrate to grpc-dotnet.

Realistically, the Grpc.Core package will remain available for quite a while after that (we're not going to actively hide/remove it), but it won't be getting official support past the deprecation date.

Can .NET 5 and .NET 6 (where grpc-dotnet is fully supported) help you with migrating off of .NET Framework?

Btw, if this is about the needing to run on older windows versions (that don't have .NET Core or .NET 5+, preinstalled), please note that with .NET 5+ you can build standalone single-file deployments, which remove the need to pre-install stuff on machines where you're are deploying.

[Tom Teag]

Our product has a huge code base with about 1000 developers. You can't easily migrate such a product to a new framework version. Additionally we use features like remoting which are not available in dotnet 5 / 6 anymore 

So it requires a lot of refactoring first to be migration ready. We thought by switching to our ipc grpc we a ready for the future. But now the grpc support got dropped and no alternative is given. Actually I don't understand the decision. I think we are not the only project in large enterprise environments which can't migrate so easy their code base to something new. And since especially such ipc frameworks like remoting and wcf got dropped by   dotnet 5 /6 and grpc was recommended as an alternative by Microsoft, we can't use it as well as long as we can't migrate the whole system. but to be migration ready we need to get rid of such old communication frameworks.... it's like an unresolvable ring dependency 

[Oskar Johansson]

We are in a very similar situation. We are currently replacing old .NET Remoting with gRPC (grpc.core, that is) since we are still stuck on .NET Framework 4.7.2. Our goal is to move up to .NET 5/6, however, we have quite a bit until we reach there. Switching from .NET Remoting to gRPC is only one of the blockers we have to resolve. It's a quite massive application (it has been actively developed for maybe 12-13 years or something, or something like that, originally targeting .NET Framework 1.x), just replacing the remoting layer with gRPC has taken us a couple of months. We started the replacement work this spring (2021), and we are almost there now. However, resolving the rest of the blockers (C++ libraries compiled for .NET Framework of various versions etc), a WCF API for third party users we provide etc. is still to resolve - we are probably a couple of years away from leaving .NET Framework.

Trust me, I'd prefer grpc-dotnet, however, since it's not available for .NET Framework, we don't have that many options.

Any possibilities to reconsider? Or somehow make grpc-dotnet work on .NET Framework?

/Oskar Johansson

Clavister

[Alberto Chiesa]

Same situation here. Pretty large codebase, with some hard dependencies on .NET Framework (for us it's mainly WCF), which needs to be migrated gradually, while still staying on .Net 4.7.2.

grpc-dotnet is not and will never be a viable option (at least during the migration process): it requires either Windows 11 and .Net Framework 4.6.1+ (talk about long time support) or .Net Core 3.

We need something that is available in .Net Framework 4.7.x and capable of running on Windows Server 2016, which is going to stay around for long (End of support 2027).

Deprecating Grpc.Core is in any case the way to go, I understand it, but I would say the current plan is anticipating a reasonable timeline by 5 years.

Alberto Chiesa

SEA Vision

[Kris Kros]

Same situation here. Can't easily move from .net Framework to .net 6 :-(

[CEbbinghaus]

Yeah this is something that we are struggling with. with more than 1k developers and a 25+ year old product we need gRPC to get rid of System.Runtime.Remoting and as such moving to .Net 6.0 is gated behind our ability to replace Remoting with gRPC.

Ideally netstandard2.0 or 2.1 would be targeted for both the Client & Server (I understand why the server is built ontop of ASP.Net Core). That way it would be avaliable to any .Net version no matter if core or framework.