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

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

Open
davidcorbin-atmosera opened this issue May 24, 2024 · 5 comments

Comments

@davidcorbin-atmosera
Copy link

Any attempt to build gets over 100 errors of the above type.

The declarations are in LinqBridge.cs

I need a debug version so that I can track down a problem in another library that depends on Newtonsoft.Json so migrations etc, is not an option....

I am just trying to understand how this builds....

Trying to (ideally) target 8.0.205 -- using VS-2022

@bartelink
Copy link

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

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

bartelink commented May 24, 2024

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

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

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.

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

2 participants