error CS0104: 'Func<,>' is an ambiguous reference between 'Newtonsoft.Json.Serialization.Func<T, TResult>' and 'System.Func<T, TResult>'

[davidcorbin-atmosera]

error CS0104: 'Func<,>' is an ambiguous reference between 'Newtonsoft.Json.Serialization.Func' and 'System.Func'

from newtonsoft.json.

[bartelink]

You're best off asking stuff like this on stackoverflow.com - this repo is for confirmed issues or feature requests; you'll get more eyes, and more responsive eyes over there

When you do, best to mention commit ids, branches etc, and commands you're issuing etc.

[davidcorbin-atmosera]

You're best off asking stuff like this on stackoverflow.com - this repo is for confirmed issues or feature requests; you'll get more eyes, and more responsive eyes over there

When you do, best to mention commit ids, branches etc, and commands you're issuing etc.

Generally I would agree... But this is very much confirmed and specific...

From the .csproj
<TargetFrameworks Condition="'$(LibraryFrameworks)'==''">net6.0;net45;net40;net35;net20;netstandard1.0;netstandard1.3;netstandard2.0</TargetFrameworks>

NO .Net 8.0

From the global.json

"version": "6.0.400",

Again not 8.0.205.

I was at least hoping one of the people familiar with the repository [not with the NuGet package or using it] might point out a branch that I have missed or if there are any plans, considering that the recommendation is generally to use the native .NET supplied serialization moving forward [but it will be decades before all libraries that depend on this one are updated or replaced].

[bartelink]

To prove you right...
This repo is effectively unmaintained
Yes, there are highly knowledgeable lurkers. But that's also true on SO.

Quick answers that you'll get better detail on on SO:

• The TargetFrameworks list is about specific package variants - there is no need to have a net8.0 as there is nothing special that the impl can take advantage of

• The global.json pins a SDK that something is known to specifically build and pass the tests with.

  • you could get and install that SDK
  • a PR could update it (but it would take ages to merge)
  • you could add a "rollForward": "major" and it will probably build. but it might not, which is why the default is not to do that
  • a 6.x in there is not 'wrong', even if it it may be a little surprising

So in summary:

1. nothing is going to break just because ther is no net8.0 TFM specific build, so I'd say this is a) not a surprise and b) also not a problem that needs resolving as such. (If this was STJ itself, it would be surprising if there wasn't some fancy new feature that would light up better and/or only on a newer TFM, but JSON.NET is not gaining new features, and supports many very spartan environments)
2. re global.json being behind / secret branches / advice from the maintainer community... No, you are not missing anything - the last work done on it was done by people that had the SDK installed. They are likely working on other things and very ikely have v8 or V9 SDKs installed (and no objection to progress) so a PR to update it would not be refused. But, don't hold your breath about it being merged quickly.

None of this is specific to this project - it's general advice about what to expect from a repo that has very low maintainer time being invested at the present time.

[davidcorbin-atmosera]

@bartelink - Well, not totally unmaintained - there was a commit onto master just a few hours ago....
What you posted is generally correct, but not related to my specific issue.

Yes, it would be possible to add older SDK's and tools to my environment to build using other versions - but that is NOT what I am asking...

There are lots of conditionals within the codebase so getting a .csproj file that has the "right things" defined for a .NET 8.0 environment without having any of the other configurations is very specific to this repository. In fact specific to https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Newtonsoft.Json.csproj.

I still figure that if someone has gone through the work (maybe on a branch, maybe just local on one of their machines) they are more likely to be in the audience of people monitoring this repository, than all of the millions (potentially) of people who use and have questions about usage or functionality, not buildability.

[bartelink]

there was a commit onto master just a few hours ago....

I stand corrected lol

I guess it was worth a shot, but if you have a closer look at the PRs and issues (I watch this repo and have for quite some time), you might not have as pesimistic a view that someone would have invested the time.

I'd either get myself the SDK ref'd in the global.json if I were you; failing that, a PR to update to latest would defintely be useful, as it will most likely be needed for a security patch etc in the near future.