[CLOSED] Where is the Newtonsoft.Json.dll dependency built/taken from?

Page 1 of 2 12 LastLast
  1. #1

    [CLOSED] Where is the Newtonsoft.Json.dll dependency built/taken from?

    Hi, I'm using Ext.NET and S#arpArchitecture together in a project. Both of them depend on Newtonsoft.Json.dll.
    However, the Newtonsoft.Json.dll that comes with Ext.NET has a different public key than the one that comes with S#arpArchitecture. Because of this, I have to recompile S#arpArchitecture with the Newtonsoft.Json.dll that comes with Ext.NET (not the other way around because in my exprience, Ext.NET has a bigger chance of using recent additions to Newtonsoft.Json.dll) every time one or the other is updated.

    I'm thinking of convincing the S#arpArchitecture guys to use the same build of the Newtonsoft.Json.dll as you Ext.NET guys do but first I have to know where it comes from.

    Please let me know so I can perhaps save me (and other guys in the same situation as me) a lot of hassle.
    Last edited by Daniil; Oct 21, 2011 at 4:40 PM. Reason: [CLOSED]
  2. #2
    Hi,

    At one point in the past, the Json.NET assembly was not being signed, so we had to create a key and compile locally. I'm not entirely sure if the current build we're using still had that problem.

    Let me do some research into this issue and I'll get back to you with an update.
    Geoffrey McGill
    Founder
  3. #3
    I don't mean to sound impatient and all but did you perhaps find out about this already? Thanks.
  4. #4
    I have exactly the same issue.
    Sharp Architecture 1.9.6 and Ext.Net 1.2.0 depend on Newtonsoft.JSON.dll with different keys.
    Can anybody propose a solution for this situation?
    Thanks!
  5. #5
    Hi,

    You could download the Ext.Net sources and build it with an Newtonsoft.Json.dll that you need.

    Or take the Newtonsoft.Json.dll from Ext.Net, it's here:
    <Ext.Net root>\Ext.Net\Build\ReferenceAssemblies\Json.NET\Newtonsoft.Json.dll
    NOTE:

    Marked as closed. Please feel free to update with a new info.
    Last edited by Daniil; Oct 21, 2011 at 4:41 PM.
  6. #6
    Until shortly, I could manage this by recompiling SharpArch. But now, since both Ext.NET and SharpArch come as NuGet packages, I'd really like to reference both of them using NuGet.

    I have checked the public keys of both the SharpArch version of Newtonsoft.Json dll and the Ext.NET version and they are still different.

    It appears SharpArch is referencing Newtonsoft.Json.dll from NuGet so if you guys would do the same, all will be fine!

    So, could you please update the sources to reference Netwonsoft.Json.dll from NuGet instead of including a custom build?
  7. #7
    Hi,

    We will update the Newtonsoft.Json.dll to 4.0.8 (the last one at the moment).

    So, the next v1.3 release will include that version.

    Hope this helps.
  8. #8
    Hi Daniil,

    I think we'll be fine as long as the public key of that dll matches the public key of the one that is on NuGet. You see, when the public key is the same, we can use version redirection in the config file. If the public keys are different, there is no way.

    Thanks!
  9. #9
    I don't think simply updating Json.Net to the latest version in the current Ext.Net build process will be an effective solution. This issue is caused by Json.Net being signed by different keys over the course of time, but as is evident by this thread Ext.Net is not the only framework library to reference this assembly. What about other frameworks that reference an older signed version of Json.Net - this problem will still exist even if Ext.Net uses the latest one.

    This issue is compounded by the fact that version 3.5 of the Json.Net NuGet package has a different public key to the version 3.5 that Ext.Net is referencing; which removes the ability for us to use binding redirects.

    Considering that Ext.Net is delivered as a NuGet package, it should really have a dependency version specified on the Json.Net package. That way referencing the package would pull down a known working version at install time. It won't capture all edge cases, but at least having the option to overlap version ranges will be there. Due to the signing, we all need to reference the assembly from the same source, i.e. nuget.org.

    I think we can agree that strong named signing is complicit in general here, but this will keep happening if the current deployment stays as is. There's plenty of chatter about this on codeplex : http://nuget.codeplex.com/discussions/247827. Interesting problem.

    Steve
  10. #10
    Quote Originally Posted by Daniil View Post
    Hi,

    You could download the Ext.Net sources and build it with an Newtonsoft.Json.dll that you need.

    Or take the Newtonsoft.Json.dll from Ext.Net, it's here:
    <Ext.Net root>\Ext.Net\Build\ReferenceAssemblies\Json.NET\Newtonsoft.Json.dll
    NOTE:

    Marked as closed. Please feel free to update with a new info.
    This isn't a working solution, especially when using NuGet + build time package installs. The only way this would work in this scenario would be to maintain a private feed with a custom Ext.Net built package on it and install from there. That's not going to be possible for the majority of customers.
Page 1 of 2 12 LastLast

Similar Threads

  1. [CLOSED] 'Newtonsoft.Json loading problem.
    By Bert76 in forum 1.x Legacy Premium Help
    Replies: 5
    Last Post: Sep 06, 2013, 11:27 AM
  2. Replies: 1
    Last Post: Mar 26, 2012, 3:54 PM
  3. NewtonSoft.Json V4.0.5.14411 /w Ext.Net V1.0.xxx.xxx
    By Daniel.Dority in forum 1.x Help
    Replies: 4
    Last Post: Mar 02, 2012, 9:21 AM
  4. [CLOSED] Newtonsoft.json
    By rthiney in forum 1.x Legacy Premium Help
    Replies: 3
    Last Post: Nov 09, 2011, 2:26 PM
  5. [CLOSED] Newtonsoft.Json, "Could not load"
    By pkellner in forum 1.x Legacy Premium Help
    Replies: 6
    Last Post: Mar 24, 2009, 11:40 PM

Tags for this Thread

Posting Permissions