Skip to content
This repository has been archived by the owner on Jun 9, 2024. It is now read-only.

Migrating this library to .Net Standard 2.0 #3

Open
prabhakarreddy1234 opened this issue Apr 6, 2019 · 13 comments
Open

Migrating this library to .Net Standard 2.0 #3

prabhakarreddy1234 opened this issue Apr 6, 2019 · 13 comments
Assignees

Comments

@prabhakarreddy1234
Copy link

prabhakarreddy1234 commented Apr 6, 2019

Since this library is built on a decade old .Net Framework 2.0, It's not compatible with latest applications such as apps built on .Net Core, Serverless etc.

I suggest migrating this library to .Net Standard 2.0 so that it will be compatible with both legacy and latest frameworks.

@robotdan
Copy link
Member

robotdan commented Apr 6, 2019

We've also had a request to deliver this using .NET core. (issue #2) I do not know much about .NET, would this also be a compatible choice?

We initially built this library to integrate with Unity. This is the primary reason it targets such an old version.

Thanks for the feedback!

@prabhakarreddy1234
Copy link
Author

.Net Standard is Microsoft answer for compatibility across Universal Windows applications i.e .Net Framework, .Net Core, Mobile Frameworks etc.

So if you migrate your library to latest .Net Standard 2.0 then it works for every framework in Microsoft.
Unity is supported in .Net Standard as well.

While migrating it i don't think there is need for much code change except for Restify library. If possible use RestSharp.

@robotdan
Copy link
Member

robotdan commented Apr 6, 2019

Thanks for that explanation! Perhaps it won't be much work to get it migrated.

Thanks!!

@robotdan
Copy link
Member

robotdan commented Jun 7, 2019

Hi @prabhakarreddy1234 we have a .NET Core library now.
https://github.com/FusionAuth/fusionauth-netcore-client

We don't have it in NuGet yet, but take a look and see if it will work for you.

@tombeany
Copy link

tombeany commented Sep 25, 2019

Hi @robotdan we have just upgraded to version 1.9.1 (I believe you helped me with a few issues on StackOverflow thankyou)
The upgrade to fusion auth has introduced application level JWT settings namely application.loginConfiguration.generateRefreshTokens and application.loginConfiguration.allowTokenRefresh
These weren't an option before so refresh tokens were returned by default via the login api.
We have a client application (.NET framework 4.7.1) that exports users and applications to fusion auth however due to the upgrade we need to set the generateRefreshTokens and allowTokenRefresh flags to true when our applications are created.
Previously we were using FusionAuth.Client v 1.6.0 the features we need are in FusionAuth.Client v1.9.0 unfortunately as I can see from this thread it was built as a .NETCoreApp and not a .NETStandard library meaning we cannot bring this dependency into our solution which is .NET framework 4.7.1 application.
This leaves us a bit stuck as we need the new client features in order to correctly work with the new API changes and functionality but cant bring it into our solution.

I noticed the latest client has dependencies on .NETCoreApp however after having a very brief look through the source I can't see why this is needed unless I am missing something. I believe removing these dependencies and converting the library to .NETStandard would make the library a lot more flexible in terms of compatibility.
The section entitled "What's .NET Standard" in this article maybe of use here

@tombeany
Copy link

Actually I may be getting confused here. So I cloned fusionauth-csharp-client and noticed this project still references .NET Framework AND has the latest API changes, which is great!
I think the confusion is caused by the Nuget packages, it seems the fusionauth-netcore-client project is now the version available on Nuget but no option to get the .NET Framework version?

@robotdan
Copy link
Member

robotdan commented Sep 26, 2019

Thanks for the feedback @tombeany ! .NET is not my strong suit!

I noticed the latest client has dependencies on .NETCoreApp however after having a very brief look through the source I can't see why this is needed unless I am missing something. I believe removing these dependencies and converting the library to .NETStandard would make the library a lot more flexible in terms of compatibility.
The section entitled "What's .NET Standard" in this article maybe of use here

Cool, I'll take a look or pass along to my team. The goal is to make the .NET core client the most compatible, so I am up for tweaks and adjustments to make it better for sure.

The fusionauth-csharp-client is still available, but it is not being updated (currently) - which means the domain may be out of sync and I'm no longer publishing it to Nuget. But if it is working for you that is great!

I think the confusion is caused by the Nuget packages, it seems the fusionauth-netcore-client project is now the version available on Nuget but no option to get the .NET Framework version?

I think so? We are using the same NuGet package but I am publishing it from the fusionauth-netcore-client instead of the fusionauth-csharp-client.

To summarize, are there things we could do to make the netcore-client compatible with your build environment or will you need the csharp-client? Is it as simple as using NETStandard instead of NETCoreApp in the netcore-client ? (I'm really .NET stupid.. )

@jgunter7
Copy link

My opinion is to target the lowest possible version of .NET Standard. Use this chart to see that .NET Standard v1 provides support to ALL of the .NET Core versions, and a few of the (eventually legacy) Framework versions as well.

https://dotnet.microsoft.com/platform/dotnet-standard#versions

Depending on the APIs that you need from .NET I think .NET Standard 2.0 would be a realistic target version, if earlier versions cannot meet the needs of this client app.

@tombeany
Copy link

tombeany commented Sep 30, 2019 via email

@robotdan
Copy link
Member

robotdan commented Oct 3, 2019

So, I'm trying to wade through all of the comments to see if I understand. :-)

If we were to use .NET Standard 2.0 or 1.1 ? this would be compatible with Windows and cross platform developers using .NET?

Ideally we'd deprecate the C# library and have "one library to rule them all" :-) . Is this possible, or will need to maintain both a "c#' and a .Net Core / Standard library to cover all of the bases?

@tyduptyler13
Copy link
Contributor

tyduptyler13 commented Oct 3, 2019

I found that I could add .NETStandard to the project without removing the .NETCoreApp compatibility and while I was in there I updated our client builder.

The fusionauth-netcore-client should be even more compatible/future proof/.net friendly.

We could build a `.nuget package that a .dll for each of the following target frameworks:

  • .NETCoreApp 2.0
  • .NETCoreApp 2.1
  • .NETCoreApp 2.2
  • .NETStandard 2.0

image

Any feedback for us non -.NET smart folks? :-)

@rdvanbuuren
Copy link

So, I'm trying to wade through all of the comments to see if I understand. :-)

If we were to use .NET Standard 2.0 or 1.1 ? this would be compatible with Windows and cross platform developers using .NET?

Ideally we'd deprecate the C# library and have "one library to rule them all" :-) . Is this possible, or will need to maintain both a "c#' and a .Net Core / Standard library to cover all of the bases?

.NET Standard would just suffice, since it can be used in .NET Core and .NET 4.5 and up.
See https://docs.microsoft.com/en-us/dotnet/standard/net-standard for more information

@robotdan
Copy link
Member

Thanks @rdvanbuuren appreciate the feedback.

We've been building a .Net core library as well that we've assumed will be able to take the place of this one. https://github.com/FusionAuth/fusionauth-netcore-client

In the fusionauth-netcore-client we're targetting .Net core 2.1 and 2.2 ( https://github.com/FusionAuth/fusionauth-netcore-client/blob/master/fusionauth-netcore-client/fusionauth-netcore-client.csproj )

 <TargetFrameworks>netcoreapp2.1;netcoreapp2.2</TargetFrameworks>

Any reason you'd use this library instead of the fusionauth-netcore-client library?

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

No branches or pull requests

6 participants