LtiAdvantage
LtiAdvantage copied to clipboard
LtiLibrary
.Net 6
Hi @andyfmiller, @srijken
I am trying to build a "pure" .Net 6 version of the LtiAdvantage library and having numerous difficulties, unit tests not being found and various incompatibilities between JObject and JsonObject and so on (Newtonsoft is no longer needed when there's System.Text.JSon and so on) Do you plan to produce a .Net 6 build of the library or is the current .Net Standard build all we're likely to see? I really wanted a definitive build that leverages full .Net 6, the kind of library we'd build if we were starting afresh with .Net 6 today and had no interest in backward compatibility with .Net Framework etc.
Thanks
@Korporal What's the reason for this? We used netstandard 2.0 wherever possible to maximize compatiblity. I can see a need to add a net6.0 build for the AspNetCore library, but what advantages would building everything against net6.0 offer?
Also see: https://docs.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1#which-net-standard-version-to-target
@srijken - Hi. Well this project actually also targets .Net Core 3.1 that's what I'm referring to. Also the dependency on Newtonsoft is undesirable, In a world where we'll be targeting .Net Core 6 going forward (for our new LTI apps) having a dependency on Newtonsoft kind of undermines that.
A .Net 6 specific build of this would be a advantage to consumers who do not care about compatibility with .Net F, we don't particularly care ourselves. Ideally we'll be developing very few .Net F applications going forward.
@Korporal you could submit a pr to bring up the .NET Core 3.1 target to .NET 6, I think that is reasonable as .NET 6 is LTS. There is no reason to drop .NET Standard and one should ask them what benefit is there by targeting .NET 6 only (besides if you need access to very specific api's and data types like TimeOnly). If you needed nullable reference types, this library could move to .NET Standard 2.1.
Although moving to System.Text.Json would also be nice, it's really immature and doesn't support a long list of things. On top of that, not every project has it configured, and this would be a breaking change. I think if you wanted to submit a separate pr for this, it could be merged in at some point, but we may want to have a compatibility package for NSJ.
@Korporal Looking into this again. I think we more or less have to go to .NET6 (and maybe .NET8 later on), because we cannot upgrade some packages. that are now deprecated. Thoughts?
@srijken, @Korporal as a library I'd expect us to target netstandard2.0 and only if there are compelling new features move to netstandard2.1 and if really really compelling e.g. .net8 (but take that just as my 2ct please).
In my company we've discussed mature Newtonsoft vs shiny new System.Text.Json and decided it's not an compelling upgrade and we'd rather wait for System.Text.Json to mature (much) further before reconsidering that decision. But to be honest this is for a mature complex product with customers that consume our API.
I hope my take helps @srijken but again please treat it as my 2ct.
Net standard is dead (see .net teams recommendations) and system text json is mature. .net 8 added a lot of great things. I'd only support latest lts unless a company wants to sponsor development time or money towards maintaining an old runtime.
TL;DR dropping .Net standard/Framework while still being widely used will hamper LTI Advantage/LTI1.3 adoption.
One of the strengths of this library is that it can be readily adopted, enabling TI Advantage/LTI 1.3 to flourish more.
I don't see a compelling reason to deviate from Microsoft's recommendation for "Reusable libraries": https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1#when-to-target-net50-or-net60-vs-netstandard
With the majority of larger companies/projects still on .Net Framework moving to .Net 6, not to mention .Net 8 in November would be an impediment for very large group of companies and projects to adopt or even keep on using this library (and thereby hindering the adoption of LTI Advantage/LTI 1.3!).
Calling certain technology "dead" does not make the real usage magically disappear overnight.
If this were not a library, I might be more inclined to agree. I also see the value (and even beauty) of modern .Net and therefore at our company I've driven a large .Net 4.5/IIS/Windows to .Net 6/ECS/Linux migration that successfully went live last Summer.
Hence though our company could readily adopt a .Net6 version of this library, we would hate to see LTI Advantage/LTI 1.3 being adopted even more slowly than it is already (despite LTI 1.0/1.1/2.x being declared insecure and deprecated over four years ago and LTI Advantage/LTI 1.3 a compelling upgrade).
Of course if @srijken (@andyfmiller is contributing less these days) would see a compelling reason (over "Xxx dead") and decide to drop .Net standard/Framework than so be it, though I hope the project does not end up with two branches to maintain and the old release being to most widely used one.
I'm not disagreeing with you... I'm saying all of this as a fellow OSS maintainer of many projects...
I'd make a bet that .NET standard will be removed at some point (https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/). From the tone of the post, previous track record and seeing public interactions with the .NET Team and their recommendation to target framework...
Regardless, this project has minimal resources and focus should be on what makes it easiest for the current active contributors to target and support (which is probably LTS or .NET Standard 2.1 if it supports everything with very little work). If a consumer wants or needs .NET 3.1 or .NET Standard than use an older package version or actively support with resources and contribute to the project.
have to go to .NET6 (and maybe .NET8 later on), because we cannot upgrade some packages. that are now deprecated. Thoughts?
@srijken Just a thought: if some dependencies are deprecated and they should be upgraded/updated then I'd see that as a compelling reason to push ahead (also in light of the comments of limited resources). Furthermore if companies move to .Net 6.0 they opt-in to embrace the Microsoft LTS model with 2 yearly upgrades so targeting old .Net 6 after it reaches end-of-life should be less of an issue.
@jeroenhabets As you mentioned you're doing a .net6 to 8 migration, are you also interested in the net6 build that no longer needs Newtonsoft?
@srijken as Newtonsoft still works for us and is still maintained (though @JamesNK adds no new features), it has not made it on our "must-migrate now" list. Though if we finish ahead of time, we may indeed eliminate it, as our usage is rather simple and we expect some performance benefits be it minor, and then we'd be interested.
That said, if your breaking away from .Net Framework, and if you have time to migrate to System.Text.Json, and if System.Text.Json of .Net6 is good enough, then you may as well, as that's where the .Net ecosystem is clearly headed IMHO.
Would it make since to just target .net 8? LTS release date is in less than 2 weeks? November 14, 2023