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: https://github.com/grpc/grpc-dotnet/issues/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

[shuebner]

@JamesNK Client support is not enough for me though. I need both ends.

WCF would have been my first choice anyway because of its out-of-the-box pipe transport. But that has no .NET Core support. I am not going to maintain WCF on one end and gRPC on the other (should that even be possible).

I will probably go with using SharedMemory and some serializer like MessagePack.

[TFTomSun]

I saw already that @jtattermusch is active in this repo, too. So it probably doesn't matter where to bring up that point

[jonasnordlund]

Yeah, this makes me a bit nervous. We moved to gRPC for our GIS application that relies on the MapInfo map engine, which in turn supports integration with .NET Framework 4.x apps. So we have a dependency that blocks us from moving to .NET 5+ right now.

We in turn have a plugin system that uses gRPC for IPC because it looked like it was a good way forward, so that when your map engine was ever ready to move to .NET 5+ we would already be comfortable with a modern technology there.

Further, gRPC felt like a simple-by-design (way moreso than WCF) and stable, slow moving standard to build upon so we felt bold in moving towards it. I absolutely didn't expect it to drop server-side support for .NET Framework while Microsoft still supported it, and even distributes it all the way into Windows 11 in 2021 and beyond.

I understand the design decision but it's unfortunate that this simple and efficient IPC mechanism suddenly needs to be more strongly tied to ASP .NET Core. It is so much more than that. It's indeed a popular scenario to find it used in but, still, it is undeniably ultimately a subset of what gRPC was designed for.

We don't want to use WCF with a ten foot pole as this would be going backwards and put is in a much worse position for migration to .NET 5+ in the future.

[jonasnordlund]

I will probably go with using SharedMemory and some serializer like MessagePack.

Thank you for posting these ideas. From a cursory glance it looks like they might work. We're really only after an abstracted and easy to use IPC mechanism and no ties into other big frameworks.

[shuebner]

I will probably go with using SharedMemory and some serializer like MessagePack.

Thank you for posting these ideas. From a cursory glance it looks like they might work. We're really only after an abstracted and easy to use IPC mechanism and no ties into other big frameworks.

I would hardly call the SharedMemory library a framework, even less a big one. Same with MessagePack.

FYI, I already implemented it on our project. Dependency on MessagePack is two lines in total. Dependency on SharedMemory is less than ten lines (both client and server side). I isolated those few lines of usage even further away behind two simple custom interfaces ISerializer and IBinaryRpcChannel.

Most of the actual RPC stubbing code is boilerplate and could even be generated from the interface definition. Maybe I will write a Source Generator just for fun. It seems to be working fine for our simple "call a method and get a result back" use-cases (i. e. no fancy Exception stacktrace serialization or instance proxying or whatever else .NET Remoting offers).

Atm, the server side process is running as a raw Main method registering the message handling callback at SharedMemory's RpcBuffer. If we need a bit more convenient management support, we may run it as a IHostedService. Maybe not.

That's it. Very simple, at least for our project's modest requirements there. I can imagine your requirements are way more sophisticated, though.

[jonasnordlund]

This indeed sounds great for us, as well as given your description of how the implementation ended up like. While our project is pretty large, our IPC needs are basic. I meant that this grp-core package is getting ties into ASP .NET Core, a big framework, and this is what I find unfortunate as it probably played a role in why it can no longer support .NET Framework 4. I wish it had remained more separate from concrete technologies.

[shuebner]

If anyone is interested in my first try, I have uploaded a minimal example demonstrating the whole chain from .NET 5 to .NET Framework 4.8:

https://github.com/shuebner/RpcOverIpcDemo

I made the .NET Framework 4.8 projects target 32 bit, just for fun.

[jonasnordlund]

Another option that supports .NET Framework 4.6.2 and .NET Standard 2.0 might be ServiceWire @ GitHub // Why ServiceWire?

[shuebner]

This is an update from the dirty real world. Skip this comment if you don't care about exceptions.

I hope I do not end up building a worse version of half of .NET remoting, but I also need exceptions to cross the process boundaries now. I even have to rethrow them at the client side.

Serializing and deserializing exceptions is deliberately limited in .NET Core. The issue of throwing exceptions across processes is comprehensively discussed. Some approaches mentioned in the discussion are actively discouraged by Microsoft. There seems to be no standard solution

My current solution happens to be very similar to this comment. It is independent of the chosen transport or serialization method.

I have a catch-all on the server side and return a special ExceptionResponse that contains at least some rudimentary information about the original exception that is easily serializable.

public sealed record ExceptionResponse(
    int CorrelationId,
    ExceptionInfo ExceptionInfo);

public sealed record ExceptionInfo(
    string ExceptionTypeAssemblyQualifiedName,
    string Message,
    ExceptionInfo? InnerExceptionInfo = null);

The server side logs the full exception along with a random correlationId (I used MEL's EventId). The client side logs the ExceptionInfo (the record's ToString() does a decent enough job) along with the correlationId. Using the correlationId, the server's log statement can be used manually or automatically to enrich the rudimentary information in the client's log.

For throwing on the client side, I check if the client runtime knows the exception type. If yes, I naively try to construct an instance of that type with one of the constructors taking a message and possibly an inner exception. If that succeeds, I throw it. If it fails (e. g. when the server side threw a RemotingException and the client side is .NET 5), the RPC libary cannot decide on its own which exception to throw instead because it does not know how the specific application handles exceptions. The library thus requires the specific application to supply a "default exception reconstructor" to use in such cases. In my particular project there is a base exception class that the RPC target interface defines and that can thus be used as the default exception.

I may update my proof of concept at some point with this, but I make no promises ;-)

[jtattermusch]

Hi All,

I'd like to understand more about what's being asked for in this issue. I totally understand that requiring to run your server on ASP.NET Core might be difficult do for some workloads, but currently there's no other way to get a well-supported HTTP/2 server-side stack on .NET - besides the native dependency trickery used by Grpc.Core, which has lots of its own problems, as described in the blogpost. I think it's inevitable that over time, there will be less and less software that supports .NET Framework 4.x (which is now "Legacy" and that's been known for a long time) and more software will require some of the more modern .NET versions. gRPC is no exception and since we're trying to stay up-to-date and relevant, it's also quite understandable that at some point we'd need make this decision, especially if dropping the support for legacy .NET frameworks allow us to have a cleaner implementation and reduces the maintenance burden by a lot. So, if we accept that at some point gRPC's support for the legacy .NET Framework will inevitably go away, what are some concrete steps we could take to make this easier for the users?

• One of the obvious answers is "don't drop Grpc.Core support just yet", but I'm not sure if this would actually help with anything, since supporting Grpc.Core for longer time would just increase the duration of the status quo, without giving any real answers (and eventually everyone would need to move grpc-dotnet anyway).
• Besides that, is there anything else that can realistically be done? At this point I'm just trying to brainstorm ideas what could be done to make it easier for users to transition off of Grpc.Core.

[shuebner]

• Besides that, is there anything else that can realistically be done? At this point I'm just trying to brainstorm ideas what could be done to make it easier for users to transition off of Grpc.Core.

We cannot transition to gRPC server, period. We are stuck with .NET Framework on parts of our application because of 3rd party dependencies. The 3rd party has declined to target anything but .NET Framework because they heavily rely on .NET remoting and do not want to refactor everything. There is nothing we can do about that. We also do not want that to keep us from going forward with .NET 5+ as much as possible.

This means we need a way to have a small .NET Framework RPC server where we can encapsulate everything that depends on .NET Framework. I personally do not care how, as long as it is highly performant. The client should be .NET 5+.

I assume that WCF is more established and more widely used and supported compared to gRPC.Core for .NET Framework. If a .NET 5 gRPC client could be configured to communicate with e. g. a WCF server, that would be enough for us. I may not like configuring two complex products, but using tested off-the-shelf libraries instead of some code from some guy (in this case me) has an appeal.

[jonasnordlund]

Yes, we're also simply in the situation of relying on .NET Framework components as explained earlier. We don't want to be where we are, but it is what it is. Other than a migration guides to competing technologies I don't know much that can be done really. I've contacted Precisely about .NET Core/5+ support in MapInfo Professional and the answer was basically "Yes, but it's hard." They're in turn in the unfortunate situation of wrapping a multi-year effort to migrate their platform off C++ to .NET Framework right when .NET Core was announced. I can understand their situation too.

Since all we're really looking for is a simple IPC mechanism that doesn't even need to use HTTP (but it doesn't hurt either), I'm going to look into one of the other technologies brought up in this thread... when I have time to. ;-) (but I will have had time by the time Grpc.Core is finally sunset for .NET Framework)

So no worries from me, really. At least there are options and we'll move to .NET 5+ as soon as we can!

[TFTomSun]

@jtattermusch one possible answer could be: deprecate grpc.core when .net framework is deprecated. As far as I know, there's not even a deprecation date yet for .net 4.8.

As stated by the other comments, there are plenty of reasons why a software cannot be migrated easily within one year, some not even within 5 years. In our case it's simply the size of the software project. We have over 1000 developers working on it in for a quite conservative business. I feel comparing an ipc framework with any other library doesn't fit. An IPC framework is used to cross the technology boundaries, at least that's one of the promises that a micro service architecture is giving us. Saying that there's a newer technology stack available now and leaving us in the old technology stack without any possibility to break out of it is the point that I don't understand. grpc promises to be cross platform, cross technology... there are still alot of grpc.core users... you can see it from the download numbers of grpc.core. Just because the technology stack we rely on is old, taking away an existing implementation for it by deprecating it within one year is disappointing for all those who are partly caught within an old technology stack. The assumption of the blogpost that it's the preference of C# devs to migrate to grpc-dotnet (on sever side) is only true for those who can easily migrate to .net 5 or who are already on .net 5... I'm not even sure if this is alresdy the majority right now.

In contrast to the others answers we would like to use the grpc ipc framework and not any other ipc framework because of its compatibility with many other technology stacks, it's performance and maturity.

[jonasnordlund]

I'd also like to add that since .NET 6 is the very first LTS release since unification of .NET Core and .NET Framework, the announcement came off as a bit of a surprise given that .NET Framework was supported in Grpc.Core. Indeed, .NET 6 will have been released by the time of Grpc.Core abandoning .NET Framework support, but the time frame between these two events are amounting to months which is barely anything to work with for a large enterprise product with its own set of features planned a long time ahead.

Yes, there has been years with .NET Core 1.0 to 3.0 as well as .NET 5, but these products have either been severely lacking in some areas for users coming from .NET Framework, not been LTS releases and thus unsuitable for the enterprise, or both.

This feels like a typical issue of different perspectives where a move to .NET Core tech is nothing special for someone living in the world of IPC and web servers, but a big deal for someone living in the world of GUI-based enterprise applications.

I also do agree with the above post and might emphasize that using gRPC would have been optimal for us (it's well documented and supported in many scenarios), but this looks like it will become a forced choice with no real migration path, so this is why we need to look at alternatives.

[Smaug123]

Could someone please confirm or refute my understanding that grpc-dotnet supports neither the .NET Framework (confirmed ad nauseam above) nor macOS in production (until https://github.com/dotnet/runtime/issues/27727 can be fixed)?

The docs at https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-5.0&tabs=visual-studio and https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-5.0#unable-to-start-aspnet-core-grpc-app-on-macos state:

macOS doesn't support ASP.NET Core gRPC with TLS. Additional configuration is required to successfully run gRPC services on macOS.

To work around this issue, configure Kestrel and the gRPC client to use HTTP/2 without TLS. You should only do this during development. Not using TLS will result in gRPC messages being sent without encryption.

[davidfowl]

Why wouldn't WCF be the answer if you needed to host a .NET Framework server component and call it from .NET Core/5+?

[TFTomSun]

@davidfowl that's the first real alternative proposal I got and if that is the long term suggestion from Microsoft it would be good to have it in the docs. Currently the docs suggest to migrate away from WCF to GRPC. Just out of curiosity ... can WCF services be called from other technology stacks as well? Are there some client generators available .e.g for typescript?

[davidfowl]

@davidfowl that's the first real alternative proposal I got and if that is the long term suggestion from Microsoft it would be good to have it in the docs.

I agree. The guidance today isn't nuanced and that might be one of the reasons for confusion. We ported the WCF client to .NET Core in the first version because of situations like this. If you must communicate with a .NET Framework server then your only real options are WCF/HTTP as there's no remoting on .NET Core/5+.

can WCF services be called from other technology stacks as well? Are there some client generators available .e.g for typescript?

I'm not sure there's a first class client generation experience for typescript here but I'm not sure what the scenario is. The guidance might require a flow chart ending with some technology depending on what you're trying to accomplish. Does your .NET Framework application need to expose a cross platform interface for all languages? Can it only be exposed to another .NET Core/5+ process instead?

[shuebner]

@davidfowl Thanks for bringing up WCF again. Where were you a month ago :wink:? I agree with your comment about the documentation. It seemed to always say: WCF is not supported in .NET Core. Migrate to gRPC. This turns out to be false.

It seems to me that this entire discussion would have been unnecessary if the documentation (or even just the community .NET Core WCF server project) would have mentioned that there is an official .NET Core WCF client.

The doc about remoting being obsolete links to .NET Framework technologies unavailable on .NET Core and .NET 5+, which explicitly mentions WCF. Although I could swear the link was not there when I read it first, it now links to a ommunity-driven port of WCF server to .NET Core. This is still in pre-release, though, so not exactly an attractive ready-to-go alternative for legacy production code-bases yet. Curiously, it does not link to the official .NET Core WCF client, which is the only missing piece to support our common use-case.

I may look into using a .NET Framework WCF server and the .NET Core WCF client later. I hope I do not get performance issues or other trouble when going down the less travelled road of using WCF with pipe transport, which the official .NET Core client seems to also offer. For now, I will stay with my own already-working approach until the first problems arise (and I am sure they will :wink:).

[TFTomSun]

@davidfowl We carve out a part of our application and currently use Blazor Server + Webview2 to reintegrate the carved out component into our win forms based application. We might want to switch to Blazor Wasm or even pure typescript for other components that we integrate in the same way (using webview2). Depends on the teams preferences. For that it would be good to offer a generated typesafe client for each wcf service version that we expose. I think Typescript and C# support should be sufficient.

[davidfowl]

My current guidance would go something like this:

1. If you cannot change your clients away from WCF and you need to take your WCF server component forward, stick with .NET Framework or consider CoreWCF (which is a community port of WCF server running on top of .NET Core/5+).
2. If you need to communicate with a .NET Framework application from .NET Core/5+, and the server needs to be in the .NET Framework project, then use WCF. Host the WCF endpoint in the Server application and use the official .NET Core WCF client to talk to it from .NET Core/5+.
3. If you need to communicate with a .NET Core/5+ application from .NET Framework, then use gRPC. The gRPC server is written in .NET Core/5+ and you can use grpc-dotnet's .NET Framework client support to talk to any gRPC server.

@TFTomSun

If you need to talk to a WCF server from a Blazor WASM application, the guidance above (2) would say to use the official WCF client. I'm not sure how well tested this is but it seems like that would be a reasonable solution.

As for typescript, there's probably a WSDL to TypeScript client generator tool on npm somewhere (e.g https://www.npmjs.com/package/wsdl-to-ts)

TL;DR hosting a gRPC server will be a .NET Core/5+ endeavor going forward.

[lsoft]

@jtattermusch my need is different that support net framework for the server, but I need to migrate a console grpc-core server to grpc-dotnet. so now I need to throw away my program design, my DI, rewrite and rebind a lot of stuff. as I understand supporting http2 needs in asp.net webserver. I'm not familiar ASP.NET (yes, we still exist :) ) so, that rewriting is a challenge for me))

(also, I think, having a whole webserver under the hood is not good from theoretical point of view - webserver is a first target for network attacks. it's increasing an attack surface. I may wrong).

so I urge MS to

1. give us a migration guide for different scenarios (am I lost it?)
2. discuss internally or with the community the point that we need to asp.net for modern grpc-dotnet EVEN we don't actually need http2, make the decision and share it.
3. please do it before grpc-core deprecating date))

Thank you!

[davidfowl]

@jtattermusch my need is different that support net framework for the server, but I need to migrate a console grpc-core server to grpc-dotnet. so now I need to throw away my program design, my DI, rewrite and rebind a lot of stuff. as I understand supporting http2 needs in asp.net webserver. I'm not familiar ASP.NET (yes, we still exist :) ) so, that rewriting is a challenge for me))

We should have a good migration guide for this. Just pretend it doesn't say ASP.NET and maybe you'll feel better about it 😄.

(also, I think, having a whole webserver under the hood is not good from theoretical point of view - webserver is a first target for network attacks. it's increasing an attack surface. I may wrong).

You're always using a webserver... Not sure what you mean. Maybe you're saying you only want the bare minimum to support grpc? So a fully featured HTTP/2 server?

@JamesNK @jtattermusch Do we have migration guidance today? It would also be much easier with .NET 6 and the new minimal APIs that will help out people like @lsoft that don't know (or care much) about using ASP.NET Core.

[lsoft]

@davidfowl I meant 2 points.

1. theoretically it's better to have a minimum network related code running yeah? attack surface etc... not sure it will helpful to discuss it, let's forget it!
2. there are people who need to migrate from old grpc to the new cool sexy grpc-dotnet. please do not force us to adopt an asp.net tech with embedded DI, configuration etc. We already have a DI, configuration in our app... we need only modern grpc and it would be cool to adopt only it, if it's possible.

So a fully featured HTTP/2 server?

There are dinosaurs like me who not familiar with asp.net and webservers so I can easily agree with you. If it's inevitable to have a lot of stuff under the hood, could I ask only to hide/remove the things I can see and I don't need (configuration, DI etc)? Hope I'm not the only only who need it.

[davidfowl]

theoretically it's better to have a minimum network related code running yeah? attack surface etc... not sure it will helpful to discuss it, let's forget it!

I agree, that's important! I don't think using Kestrel for HTTP/2 exposes any more attack surface than.

there are people who need to migrate from old grpc to the new cool sexy grpc-dotnet. please do not force us to adopt an asp.net tech with embedded DI, configuration etc. We already have a DI, configuration in our app... we need only modern grpc and it would be cool to adopt only it, if it's possible.

They'll have to, but don't worry, it'll be mostly hidden if you don't want to use it. Treat it like an implementation detail.

There are dinosaurs like me who not familiar with asp.net and webservers so I can easily agree with you. If it's inevitable to have a lot of stuff under the hood, could I ask only to hide/remove the things I can see and I don't need (configuration, DI etc)? Hope I'm not the only only who need it.

Of course! .NET 6 does a really good job of hiding a lot of the fluff.

[JamesNK]

@JamesNK @jtattermusch Do we have migration guidance today? It would also be much easier with .NET 6 and the new minimal APIs that will help out people like @lsoft that don't know (or care much) about using ASP.NET Core.

Migration guidance is here: Migrate gRPC from C-core to gRPC for .NET

[whoisj]

😢 having to drag ALL of ASPNET into our existing solution creates a massive new attack surface we have to figure out how the hell to defend. Is there a cheap 'n cheerful way to shutdown every damn thing ASPNET does except minimum necessary to mimic what Grpc.Core (the deprecated lib) does already?

[JamesNK]

You can configure the port to only use HTTP/2. Otherwise asp.net core is pay-for-play. For example, if you don’t add authentication services or middleware then your app doesn’t use it.

I’ll point out that while Grpc.Core is one Nuget package, it is huge. Written in C++, it has its own http client, http server, http2 implementation, TLS implementation (boringssl), grpc client and grpc server. I assume it pulls in various C++ libraries as well. Then .net wrappers over the top.

[TFTomSun]

@JamesNK @jtattermusch Do we have migration guidance today? It would also be much easier with .NET 6 and the new minimal APIs that will help out people like @lsoft that don't know (or care much) about using ASP.NET Core.

Migration guidance is here: Migrate gRPC from C-core to gRPC for .NET

That migration guide doesn't contain the WCF use case (existing Grpc.Core NET48 server which needs to migrated back to WCF). Instead, next to that migration guide, is the migration guide "Why migrate WCF to ASP.NET Core gRPC" 😜

[JamesNK]

It is a migration guide for migrating to gRPC for .NET. Not migrating away from Grpc.Core.

[Smaug123]

It is a migration guide for migrating to gRPC for .NET. Not migrating away from Grpc.Core.

Its title is "Migrate gRPC from C-core to gRPC for .NET". I quote its contents:

NuGet packages, configuration, and startup code must be modified when migrating from gRPC C-Core to gRPC for .NET. ... When migration is complete, the Grpc.Core package should be removed from the app. Grpc.Core contains large native binaries, and removing the package reduces NuGet restore time and app size.

It's early in the morning for me; what am I missing? If it's not a migration guide for migrating gRPC away from Grpc.Core to gRPC for .NET, why does it have the title "Migrate gRPC from C-core to gRPC for .NET" and contents telling you to remove Grpc.Core from your app when you're done?

[JamesNK]

It is a migration guide for Gpr.Core to gRPC for .NET. These docs are for gRPC for .NET.

The context of my comment was about why it doesn't make sense add how instructions to migrate from Grpc.Core to WCF. That content is about migrating away Grpc.Core and not migrating to gRPC for .NET. It has nothing to do with gRPC for .NET and doesn't make sense to add to this doc. It would make more sense to add it to Grpc.Core docs.

[whoisj]

ahh I see the disconnect (for me) ASPNET != ASP.NET == ISS

my assumption was that use of Grpc.Net would drag in the entire ASP.NET ecosystem, and I was completely uninterested in the ability to serve .apsx pages. 😅

[sanderploegsma]

3. If you need to communicate with a .NET Core/5+ application from .NET Framework, then use gRPC. The gRPC server is written in .NET Core/5+ and you can use grpc-dotnet's .NET Framework client support to talk to any gRPC server.

@davidfowl When calling a gRPC server from a .NET Framework application, I assume these limitations are still applicable?

[Soon5]

I tested it yesterday and they still exist. At least in my build. Not being able to have bidirectional streams or client side streaming, makes the grpc-dotnet client unusable for me. I was able to replace my server now with the new .Net Core based implementation, but my client side is stuck to .Net Framework 4.8 due to lot's of UI Winforms code. I have to admit that the replacement on server side went smooth, so no real issues there, and I can see a performance improvement. But due to the limitations on client side I need to continue using the mixed mode with the Grpc.Core Library on client side, until grpc-dotnet client catches up and can do the other 50% of stream types as well.

[jtattermusch]

Please see the latest update on Grpc.Core deprecation