search

dotnet / orleans

Cloud Native application framework for .NET
https://docs.microsoft.com/dotnet/orleans
MIT License
10.06k stars 2.03k forks source link

Support for .NET Standard 2.0 #8297

Closed mmccord-processunity closed 1 year ago

mmccord-processunity commented 1 year ago

It looks like support for .NET Standard 2.0 was dropped in https://github.com/dotnet/orleans/pull/6984 but then that maybe work was started to add it back with https://github.com/dotnet/orleans/pull/7264, perhaps due to prompting from https://github.com/dotnet/orleans/issues/6992?

I was wondering if there were plans to add cross-compilation for Microsoft.Orleans.Client and Microsoft.Orleans.SDK for .Net Standard 2.0? And to make the code generation compatible with .NET Standard 2.0 for client code. At least for now?

We have an application that is still utilizing .NET Framework. We're trying to migrate this application to .NET 7 and Orleans. As part of that plan, we would like to substitute elements of the .NET Framework application to utilize grain references by making this application a client of our Orleans cluster. But we can no longer do that with the Orleans 7 release. This really presents a challenge as our .NET Framework application has large sections of it which are utilizing web forms and doing so in a way that makes a piece-meal lift of the front-end difficult, thereby foisting the .NET Framework dependency on lower levels of the application where we'd like to utilize grain references to migrate business logic and data access to the more modern versions of .NET.

mmccord-processunity commented 1 year ago

@ReubenBond -- it looks like you were the progenitor of #7264. Is there any direction on this?

mmccord-processunity commented 1 year ago

@ReubenBond -- I just noted in this comment you are batting around the idea of 4.8.1 support...

ReubenBond commented 1 year ago

I don't think we'll add support for .NET Standard 2.0 to the framework. It is too limiting and burdensome. Perhaps we could add it for just the serializer, but I'm not sure even that warrants the effort and ongoing burden. That's what https://github.com/dotnet/orleans/pull/7264 was about: adding support only for the core abstractions and serialization libraries. Even adding .NET Standard 2.1 support in the serializer is limiting and I imagine we will drop that eventually.

In the comment that you referenced, I was mistaken: .NET 4.8.1 does not support .NET Standard 2.1, so it wouldn't have worked.

As for your particular case, you could migrate to Orleans 3.x (which will continue to receive updates for some time) with the plan of eventually migrating to 7 once you've eliminated the blockers. Does that sound viable?

mmccord-processunity commented 1 year ago

I don't think we'll add support for .NET Standard 2.0 to the framework. It is too limiting and burdensome. Perhaps we could add it for just the serializer, but I'm not sure even that warrants the effort and ongoing burden. That's what #7264 was about: adding support only for the core abstractions and serialization libraries. Even adding .NET Standard 2.1 support in the serializer is limiting and I imagine we will drop that eventually.

In the comment that you referenced, I was mistaken: .NET 4.8.1 does not support .NET Standard 2.1, so it wouldn't have worked.

As for your particular case, you could migrate to Orleans 3.x (which will continue to receive updates for some time) with the plan of eventually migrating to 7 once you've eliminated the blockers. Does that sound viable?

@ReubenBond -- To clarify, we don't need all of Orleans to be on .NET Standard 2.0. What I was asking about was specifically the client communication portion of it (core abstractions, serialization being a large chunk of that, along with IClusterClient, and some of the client-side communication management code, and generated client-side code). Does that change your assertion from above? If we could make our legacy application (which is currently on .NET Framework) a client of the Orleans cluster (which lives in .NET 7), that solves our issue. Or, is that just not in the cards?

mmccord-processunity commented 1 year ago

@ReubenBond -- the reason why I ask about the above is because per your question, it's not really viable. This process is liable to take us as much as two years to fully complete. Taking on a lengthy migration like that only to have it followed hard upon with another migration is probably a no-go. If we need to we can work around this by using an API on the back-end but being able to utilize IClusterClient and not have to build an API for this back-end communication would have been a fairly big win -- a lot less code to write and maintain.

ReubenBond commented 1 year ago

Adding support for IClusterClient would involve backporting most of the framework to .NET Standard 2.0. The approach of creating a gRPC or HTTP frontend API is likely your best bet here, I think.

ghost commented 1 year ago

Thanks for contacting us. We believe that the question you've raised has been answered. If you still feel a need to continue the discussion, feel free to reopen the issue and add your comments.