.NET Standard version

[JohnGalt1717]

Any chance of getting this recompiled into .NET Standard? As it is it's blocking upgrades. (yes with .NET Standard you can sort of us this, but you can't use it to deploy to Linux or docker as a result.)

Thanks!

[reedmclean]

My current plan is to investigate expanding into .NET Standard once we start on the next major version. Not sure on what the timeline for that would be, but I'll keep this issue updated as we figure that out!

[tidyui]

I have converted the projects to .NET Core, NetStandard 2.0 & xUnit for testing and have a new branch for it here:

https://github.com/tidyui/TinCan.NET/tree/dotnet-core

Everything is compiling and all tests are succeeding, but that's as far as I have tested it so far. I will continue to set it up and test it as I need it for a project. Let me know if you want a PR, otherwise you can always use it as reference!

Regards

[reedmclean]

That's awesome! Thanks so much for reaching out. I'm definitely going to take a look at your repo as soon as I can.

[tidyui]

The core project had no issues what so ever, I only replaced the .csproj with a modern one and everything compiled without changes :) The test repo I converted to xUnit simply because I'm running .NET Core on a Mac so I needed a cross-platform test framework.

[njvsvalhalla]

I don't know if it's worth it to mention but I also put together a bunch of the pull requests here, and also standardized method names (like going from camelCase to PascalCase), made async, etc here: https://github.com/njvsvalhalla/TinCan.NET

[JohnGalt1717]

Note also that Newtonsoft.json is dead and this library needs to be switched to System.Text.Json and that it's use of Newtonsoft is becoming highly problematic.

I don't know if it's worth it to mention but I also put together a bunch of the pull requests here, and also standardized method names (like going from camelCase to PascalCase), made async, etc here: https://github.com/njvsvalhalla/TinCan.NET

Most of the naming and even the use of JObject etc. I'm finding is because of someone that doesn't understand json serialization/deserialization in .NET writting this. This entire library should be using DTOs for most of this stuff and eliminating the use of dynamic stuff entirely.

[rrmayer]

I'm looking into possibly doing this. I think the work would take about ~1 hour.

[JohnGalt1717]

@rrmayer Thanks! This is super important because all of the old versions of .net are about to become unsupported.

[rrmayer]

They're already unsupported. And the serialization code in here is very "hard coded" as opposed to following general semantics. Looks like it will take an evening as opposed to an hour.

[tidyui]

Note also that Newtonsoft.json is dead and this library needs to be switched to System.Text.Json and that it's use of Newtonsoft is becoming highly problematic.

This was an extremely misleading comment. Newtonsoft JSON is by no means dead as System.Text.JSON only supports (and probably always will) a subset of the things Newtonsoft does. Also it would be interesting to hear how using it could be problem for you in any other way that you would like to use System.Text.JSON in your application.

[JohnGalt1717]

@tidyui .NET 6 System.Text.Json has essentially parity with Newtonsoft.Json and the author James Newton King now works at Microsoft and there hasn't been any real updates to Newtonsoft.Json since he was hired.

Further, when you have Newtonsoft.Json and System.Text.Json you can introduce subtle bugs (aside from using significantly more memory and build size in docker containers etc.) because of internal serialization and deserialization where one component uses Newtonsoft.Json and the other uses System.Text.Json. (and virtually all libraries have ditched Newtonsoft.Json now for exactly this reason).

Further it's Microsoft's and James Newton King's recommendation to switch to System.Text.Json and that's where most of his time is spent.

I.e. nothing I said was misleading.