GRPC does not appear to be a viable way forward for larger .net framework 
applications where the migration has to happen before migrating to .net x
Have you looked at CoreWCF?
https://github.com/CoreWCF/CoreWCF

tirsdag den 11. juli 2023 kl. 08.46.05 UTC+2 skrev 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.
>
> On Tuesday, 8 March 2022 at 10:50:23 pm UTC+11 Kris Kros wrote:
>
>> Same situation here. Can't easily move from .net Framework to .net 6 :-(
>>
>> [email protected] schrieb am Montag, 20. September 2021 um 14:25:09 
>> UTC+2:
>>
>>> 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
>>> Il giorno giovedì 16 settembre 2021 alle 14:02:59 UTC+2 Oskar Johansson 
>>> ha scritto:
>>>
>>>> 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
>>>>
>>>> On Monday, August 23, 2021 at 3:43:18 PM UTC+2 Tom Teag wrote:
>>>>
>>>>> 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 
>>>>>
>>>>> Jan Tattermusch schrieb am Montag, 23. August 2021 um 11:39:54 UTC+2:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> On Wednesday, August 11, 2021 at 2:55:26 PM UTC+2 Tom Teag wrote:
>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/7b794d87-4fe7-48f4-a776-c962ff752b4bn%40googlegroups.com.

Reply via email to