-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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.
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
#2294 Make Http.Client
projects usable by traditional netfx projects
#2867
#2294 Make Http.Client
projects usable by traditional netfx projects
#2867
Conversation
This makes the usage of clients in traditional .netfx applications (WinForms) possible
…ynamic-CSharp-Api-Clients-net-standard20
<IsPackable>true</IsPackable> | ||
<OutputType>Library</OutputType> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi
Why remove these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed these to be compliant with other netstandard projects in the framework directory.
EDIT: I looked those values up and IsPackable
defaults to true
and OutputType
defaults to Library
anyway.
I've found a missing detail in my customization. The
So the implementation details for these actions must be splitted. I'll edit my PR asap. |
Package contains the 'pass-through' authenticator-implementation which previously was in `Volo.Abp.Http.Client.IdentityModel.IdentityModelRemoteServiceHttpClientAuthenticator`. Since the `IdentityModelRemoteServiceHttpClientAuthenticator` implementation (without requiring `IHttpContextAccessor`) is required for basic clients (which should be able to target net-standard or netfx) this package was splitted into `Volo.Abp.Http.Client.IdentityModel.Relay` to support the known behavior of just passing the token around. WARNING: This commit contains a breaking change for existing backend applications which use automagic C# clients!
…der` The `CrossPlatformParameterTypeComparer` handles type differences in .net-core and .net-framework by replacing the assembly names with placeholders. This implementation works in all environments because the `CrossPlatformParameterTypeComparer` inherits the default behavior and (once) checks the current framework.
Hi @maliming, I've updated my PR to properly work on netfx and netcore frameworks. |
hi @NecatiMeral I merged some conflicts. |
hi @maliming Thanks for your efforts. Our preferred solution in the long-term view would be to use the upstream modules / packages instead of customizing every bit just for our needs. I think there are multiple developers who are requiring netstandard-clients for different scenarios (mobile, winforms, ...). I know that abp was created because of the huge changes in netcore3.1. For the backend aspect it's totally fine, but maybe abp should consider this compatibility for clients. the effort to maintain netstandard compatibility on client-side is pretty low. We can't use abp if the built-in-clients cannot be used in netstandard-projects because we don't want to manually generate our clients for each api version (with AutoRest for example). |
I simplified this implementation: #2951 |
I also didn't find the .Relay project naming useful. I will change it as .Web. |
Thanks for your feedback. I'll review the changes tomorrow. |
hi @hikalkan, thank you for the review / updates. Looks good to me! |
Resolve #2294
To support .NET-Framework based projects I've updated the corresponding projects to target netstandard2.0. The
Volo.Abp.Http.Client.IdentityModel
project hasn't been touched because of theIHttpContextAccessor
dependency and I think it should be used by DotnetCore (Hosts) only.