Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Evaluate Grpc.Net.Client changes for GAX impact #712

Closed
jskeet opened this issue Aug 4, 2023 · 0 comments · Fixed by #755
Closed

Evaluate Grpc.Net.Client changes for GAX impact #712

jskeet opened this issue Aug 4, 2023 · 0 comments · Fixed by #755
Assignees
@jskeet

Comments

@jskeet
Copy link
Collaborator

jskeet commented Aug 4, 2023

See:

Changing from Grpc.Core to Grpc.Net.Client seamlessly is great if it works (although it could cause some surprises in terms of logging etc). It sounds like the only cases we need to worry about are ".NET Framework, on Windows Server 2022, with an API that uses client/bidi-streaming." We could potentially detect whether any APIs use client/bidi-streaming and still fall back to Grpc.Core when on .NET Framework by default for those - or do the more complex OS check if necessary. We should work out how many APIs actually have client/bidi-streaming methods.
jskeet added a commit to jskeet/gax-dotnet that referenced this issue Nov 7, 2023
@jskeet
fix: Update gRPC adapter detection to always use Grpc.Core on .NET Fr…
563a45c 
…amework

Currently, users who have a recent (extra) Grpc.Net.Client
dependency and are using .NET Framework will default to
Grpc.Net.Client, even if it won't work due to client/bidi-streaming calls.

Eventually we'll detect this properly, but for now we can just use
Grpc.Core unconditionally on .NET Framework. (This can still be
overridden with the environment variable or explicit code, of course.)

This is part of googleapis#712, but doesn't fully address it.
@jskeet jskeet mentioned this issue Nov 7, 2023
Merged
jskeet added a commit to jskeet/gax-dotnet that referenced this issue Nov 7, 2023
@jskeet
fix: Update gRPC adapter detection to always use Grpc.Core on .NET Fr…
781270b 
…amework

Currently, users who have a recent (extra) Grpc.Net.Client
dependency and are using .NET Framework will default to
Grpc.Net.Client, even if it won't work due to client/bidi-streaming calls.

Eventually we'll detect this properly, but for now we can just use
Grpc.Core unconditionally on .NET Framework. (This can still be
overridden with the environment variable or explicit code, of course.)

This is part of googleapis#712, but doesn't fully address it.
jskeet added a commit to jskeet/gax-dotnet that referenced this issue Jan 19, 2024
@jskeet
fix: Update gRPC adapter detection to always use Grpc.Core on .NET Fr…
496cd27 
…amework

Currently, users who have a recent (extra) Grpc.Net.Client
dependency and are using .NET Framework will default to
Grpc.Net.Client, even if it won't work due to client/bidi-streaming calls.

Eventually we'll detect this properly, but for now we can just use
Grpc.Core unconditionally on .NET Framework. (This can still be
overridden with the environment variable or explicit code, of course.)

This is part of googleapis#712, but doesn't fully address it.
jskeet added a commit to jskeet/gax-dotnet that referenced this issue Jan 20, 2024
@jskeet
fix: Update gRPC adapter detection to always use Grpc.Core on .NET Fr…
cd11756 
…amework

Currently, users who have a recent (extra) Grpc.Net.Client
dependency and are using .NET Framework will default to
Grpc.Net.Client, even if it won't work due to client/bidi-streaming calls.

Eventually we'll detect this properly, but for now we can just use
Grpc.Core unconditionally on .NET Framework. (This can still be
overridden with the environment variable or explicit code, of course.)

This is part of googleapis#712, but doesn't fully address it.
jskeet added a commit that referenced this issue Jan 20, 2024
@jskeet
fix: Update gRPC adapter detection to always use Grpc.Core on .NET Fr…
2c97fa5 
…amework

Currently, users who have a recent (extra) Grpc.Net.Client
dependency and are using .NET Framework will default to
Grpc.Net.Client, even if it won't work due to client/bidi-streaming calls.

Eventually we'll detect this properly, but for now we can just use
Grpc.Core unconditionally on .NET Framework. (This can still be
overridden with the environment variable or explicit code, of course.)

This is part of #712, but doesn't fully address it.
jskeet added a commit to jskeet/gax-dotnet that referenced this issue Feb 7, 2024
@jskeet
feat: Detect grpc-dotnet support on Windows under .NET Framework
9fbae69 
This will enable more users to use grpc-dotnet instead of Grpc.Core.

Comprehensive testing is impractical, but this has been tested under Windows 10 (uses Grpc.Core) and Windows 11 (uses Grpc.Net.Client).

Fixes googleapis#712.

Note that we'll need to revisit code if a later version of Windows
Server 2022 fully supports grpc-dotnet.
@jskeet jskeet mentioned this issue Feb 7, 2024
Merged
jskeet added a commit that referenced this issue Feb 7, 2024
@jskeet
feat: Detect grpc-dotnet support on Windows under .NET Framework
bfa72ad 
This will enable more users to use grpc-dotnet instead of Grpc.Core.

Comprehensive testing is impractical, but this has been tested under Windows 10 (uses Grpc.Core) and Windows 11 (uses Grpc.Net.Client).

Fixes #712.

Note that we'll need to revisit code if a later version of Windows
Server 2022 fully supports grpc-dotnet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jskeet jskeet

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: Detect grpc-dotnet support on Windows under .NET Framework jskeet/gax-dotnet
1 participant
@jskeet