Replacement of Server functionality for .NET Framework (4.8)

[TFTomSun]

It was announced here that Grpc.Core will be phased out and grpc-dotnet should be used instead. As far as I know Grpc.Core is the only package that supports a gRPC server on the old .NET Framework. Will there be support for a server implementation from grpc-dotnet side that supports the old .NET Framework (e.g. 4.8) ?

[JamesNK]

No there won't be support for .NET Framework server in grpc-dotnet. The new server implementation is built on ASP.NET Core and requires HTTP/2 support that is only available in .NET Core 3 or later.

[TFTomSun]

Hm, they write that moving from Grpc.Core to grpc dotnet should be possible with a few changes, but if a dotnet framework upgrade is required to do so, where alot of legacy stuff has been removed, it is not so easy as they assume. I hope they know that they phased out the .NET Framework 4.x support with that decision.

[JamesNK]

Yes, they are aware of that.

[TFTomSun]

What's the suggestion from Microsoft for duplex inter process communication between a legacy .NET server and a modern .NET 5+ client? I read somewhere, Microsoft suggest gRPC as the replacement for WCF, but if the .NET framework support is dropped in gRPC, what alternatives do we have?

btw. One year ago, GRPC.Core was suggested here: #1032

[JamesNK]

Grpc.Net.Client supports .NET Framework

[TFTomSun]

So Microsoft's suggestion is to invert client and server?

[JamesNK]

I’m giving you options. I don’t know your app and what is best for you depends on your situation.

[shuebner]

Same problem here. We have to use a 3rd party .NET Framework 4.7.2 client library that relies on .NET remoting to communicate with a .NET server application. To use the client library from a .NET 5 application, we need to bridge the gap between .NET 5 and .NET Framework 4.7.2 by running different processes and have IPC between them.

We cannot use gRPC for this without .NET Framework support.

It seems we are left alone by Microsoft. There are no other IPC recommendations I am aware of. Do we really need to implement this ourselves with ProtoBuf over pipes or something?

[JamesNK]

Grpc.Net.Client supports .NET Framework today.

There is zero chance that Grpc.AspNetCore will ever support .NET Framework.

There are no other IPC recommendations I am aware of.

WCF.

[TFTomSun]

@JamesNK I can understand that decision not to support .NET Framework in the new implementation. But deprecating the old one in such a short time frame is the problem. And my assumption was that there was a misunderstanding between 2 teams in regard to what the new implementation supports and what not. This assumption is also based on their migration Q&A.

There you can find this:

Since Grpc.Core and grpc-dotnet are two distinct libraries, there are going to be some code changes necessary in your project. Since both implementations share the same API for invoking and handling RPCs (we’ve intentionally designed them to be that way), we believe that the code changes necessary should be fairly minimal. For many applications you’ll simply need to change the way you configure your gRPC channels and servers; that is usually only a small portion of your app’s implementation and tends to be separate from the business logic.

This is definitely not the case if we are forced to migrate gRPC server implementations from .NET 4.x to .NET 5. And I think that's a valid general point and has nothing to do with "my app".

[JamesNK]

If your problem is the time frame that Grpc.Core is being deprecated, wouldn't it make more sense to bring this up at its repo? https://github.com/grpc/grpc