Open xantari opened 4 years ago
Hi @xantari,
Thank you for your concerns and questions.
We did do some in-depth analysis of the technology (.NET Framework 4.6.x vs .NET Core vs .NET Standard 2.x) while trying to decide on this version. And I understand that .NET Standard 2.1 is not going to be supported in .NET Framework 4.6.x applications. However, we have also had requests from others to specifically support .NET Standard 2.1 and subsequently .NET Core 3.x.
While this may mean that we will have to maintain two parallel library efforts, it also allows us to cater to these requests from our users as well as to prepare for any technology changes in future. We also want to ensure that our users are not impacted by Microsoft ending support for .NET Core 3.0 and below.
As mentioned in #14, the .NET Standard SDK is currently targeted for Beta/Non-Production use only. We have intentionally not made the repository publicly available until we are sure that the Beta integration is successful, which should be some time in the near future.
@gnongsie I think you may be misunderstanding.
If you target .NET Standard 2.0. Then the library will work with .NET Core 2.0+ and .NET Full Framework 4.6.1+
So no need to target .NET Standard 2.1 for .NET Core 3.x support, you can target .NET Standard 2.0 and it will work just fine with .NET Core 3.x.
Please use .NET Standard 2.0 and skip this parallel library effort.
https://docs.microsoft.com/en-us/dotnet/standard/net-standard
BTW, @brutaldev version is .NET Standard 2.0. You can see it here: https://www.nuget.org/packages/CyberSource.Rest.Client.Core
Where is the Git repository for this new parallel library effort?
A huge competitor of yours has already done this analysis too, and they have also arrived at using .NET Standard 2.0 as the preferred option for the widest scope of use cases. https://github.com/stripe/stripe-dotnet
@gnongsie What is the status on this?
@xantari : Thank you for your feedback and recommendation. As already communicated by @gnongsie other Developer evangelists like you and Tech savvy Merchants through Merchant facing teams requested specifically to support .NET Standard 2.1 and subsequently .NET Core 3.x.
It was a thoughtful Business decision to cater to popular demand. Currently .NET Standard SDK is released for Beta/Non-Production test. We would like you to be our Beta user, please let us know your interest.
Where is this Git Repo for this parallel library development effort? Will it be constantly kept in feature parity with this .NET full framework library? When can we expect a production version available?
I'm still not understanding why you are saying you need .NET Standard 2.1 library to be used with .NET Core 3.x. All .NET Standard 2.0 librarys can be used with .NET Core 3.x, and even the recently released .NET 5. But they have the added benefit of also being used in .NET Full Framework 4.6.1 and above. .NET Standard 2.1 libraries can NOT be used in .NET Full Framework 4.6.1....
@chsriniv9 @gnongsie What is status on this?
@chsriniv9 @gnongsie Any updates?
Hello @xantari - SDK is recently made public. It'll be kept in feature parity with .NET full framework library. We are piloting it with few merchants, Will mark it GA as these pilot merchants successfully rolls into production.
https://github.com/CyberSource/cybersource-rest-client-dotnetstandard
Also, We understand and respect your recommendation around using .NET Standard 2.0 that is compatible with .NET Core 3.x. and .NET Full Framework 4.6.1 and above. But we had to obliged with some prior commitment to support .NET Standard 2.1. But until we are maintaining the feature parity it should not cause major concerns.
Ok, this decision has the unfortunate side effect where we will need to maintain two parallel services / business logic areas in our applications as well then (one full framework compatible and one .net core compatible).
Had this been .NET Standard 2.0 that would have bridged the gap between the two .NET Frameworks to eliminate this redundancy. I wish we had 100% .NET Core code, but like many businesses we have a lot of legacy code still in .NET Framework that we must maintain.
The other option we have though atleast is we can just download your github repo, and re-compile it as .NET Standard 2.0 and publish our own internal nuget to solve that problem.
Furthermore, one additional solution (which would be a bit longer process for us to implement) is for us to create a .NET Core API endpoint wrapper around your .NET Standard 2.1 component so that it can be consumed using the standard HttpClient interfaces (auto generated nswag client).
@londhegaurav I fail to see the reason why you would choose to go with 2.1 instead of 2.0?
"Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0. In fact, most libraries should be able to stay on .NET Standard 2.0, as the API additions are largely for advanced scenarios." - https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1
Do you have advanced scenarios you need to cater for that forces you to use 2.1? Why don't you multi-target your library for 2.0 and 2.1 to broaden the scope of support for consumers? Why don't you maintain a single library using 2.0 instead of having to duplicate them for full framework and core?
Just like @xantari I will simply have a job that regularly clones your repo, changes the target to 2.0, compiles and publishes to a private NuGet server since it works exactly the same whether you are using 2.1 instead of 2.0...
Reopening this. @brutaldev makes a lot of good points. Especially the multi-targeting.
@xantari and @brutaldev I hear you. Let me circle back with team and see how can we help you here.
@londhegaurav What is status?
@londhegaurav What's going on with this issue?
@brutaldev @xantari Sorry to keep you hanging here. We are planning to add .net core 5 support early next year. Until then we'll be managing two SDKs and samples repos(NET Full Framework 4.6.1 & .NET core 2.1).
@londhegaurav I think you are completely missing the point. Please look back above at @brutaldev response.
@xantari Do you mind emailing on developer@cybersource.com? We can have a quick sync up on this issue as well as other issues that you are looking for fix from Cybersource. Will loop in @gnongsie as well.
i'm facing this exact issue and had this exact conversation internally with my team about what this "should be" -- very much agree with @xantari and @brutaldev
This is in reference to #14
Where is the Git Repo for this implementation?
Why is the library targeting .NET Standard 2.1? This is going to require you to maintain two parallel library efforts. If you make it .NET Standard 2.0 with the current repository this issue will be resolved and you will have only one library to maintain that is .NET Full Framework 4.6+ and .NET Core / .NET Standard 2.0 compatible.