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.

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

.NET Standard / .NET Core Implementation Questions #96

Open
xantari opened this issue Nov 23, 2020 · 20 comments
Open

.NET Standard / .NET Core Implementation Questions #96

xantari opened this issue Nov 23, 2020 · 20 comments

Comments

@xantari
Copy link

xantari commented Nov 23, 2020

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
Copy link
Contributor

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
Copy link
Author

xantari commented Nov 24, 2020

@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
Copy link
Author

xantari commented Nov 24, 2020

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
Copy link
Author

xantari commented Nov 24, 2020

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
Copy link
Author

xantari commented Dec 4, 2020

@gnongsie What is the status on this?

@chsriniv9
Copy link
Contributor

@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
Copy link
Author

xantari commented Dec 4, 2020

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
Copy link
Author

xantari commented Dec 15, 2020

@chsriniv9 @gnongsie What is status on this?

@xantari
Copy link
Author

xantari commented Jan 21, 2021

@chsriniv9 @gnongsie Any updates?

@londhegaurav
Copy link

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
Copy link
Author

xantari commented Jan 22, 2021

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

@xantari xantari closed this as completed Jan 22, 2021
@brutaldev
Copy link

@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
Copy link
Author

xantari commented Feb 4, 2021

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

@xantari xantari reopened this Feb 4, 2021
@londhegaurav
Copy link

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

@xantari
Copy link
Author

xantari commented Feb 26, 2021

@londhegaurav What is status?

@xantari
Copy link
Author

xantari commented Mar 31, 2021

@londhegaurav What's going on with this issue?

@londhegaurav
Copy link

@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
Copy link
Author

xantari commented Apr 14, 2021

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

@londhegaurav
Copy link

@xantari Do you mind emailing on [email protected]? 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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants