CyberSource / cybersource-rest-client-dotnet

.NET client library for the CyberSource REST API
Other
19 stars 44 forks source link

.NET Standard / .NET Core Implementation Questions #96

Open xantari opened 4 years ago

xantari commented 4 years ago

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.

gnongsie commented 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.

xantari commented 4 years ago

@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

xantari commented 4 years ago

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?

xantari commented 4 years ago

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

xantari commented 3 years ago

@gnongsie What is the status on this?

chsriniv9 commented 3 years ago

@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.

xantari commented 3 years ago

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....

xantari commented 3 years ago

@chsriniv9 @gnongsie What is status on this?

xantari commented 3 years ago

@chsriniv9 @gnongsie Any updates?

londhegaurav commented 3 years ago

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.

xantari commented 3 years ago

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).

brutaldev commented 3 years ago

@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...

xantari commented 3 years ago

Reopening this. @brutaldev makes a lot of good points. Especially the multi-targeting.

londhegaurav commented 3 years ago

@xantari and @brutaldev I hear you. Let me circle back with team and see how can we help you here.

xantari commented 3 years ago

@londhegaurav What is status?

xantari commented 3 years ago

@londhegaurav What's going on with this issue?

londhegaurav commented 3 years ago

@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).

xantari commented 3 years ago

@londhegaurav I think you are completely missing the point. Please look back above at @brutaldev response.

londhegaurav commented 3 years ago

@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.

mrtristan commented 3 years ago

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