NewtonSoft #2121

doodlleus · 2018-06-14T11:51:06Z

The upgrade package does not include the newtonsoft.json.dll library which causes the upgrade to break if you do not already have v10.0.0.0 installed of the lib. The main install package contains it though

mitchelsellers · 2018-06-14T12:57:03Z

Can I confirm that this is an issue with 9.2.0?

doodlleus · 2018-06-14T13:16:14Z

That's correct, specifically the upgrade zip

…

On Thu, 14 Jun 2018, 13:57 Mitchel Sellers, ***@***.***> wrote: Can I confirm that this is an issue with 9.2.0? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2121 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHGCavH8BfkBkAPgfX9idWpzj42p-NAKks5t8l3VgaJpZM4Un0Iu> .

ohine · 2018-06-14T15:03:10Z

It appears the install zip contains Newtonsoft.Json.dll v10.0.3.21018 in the /bin directory and the Newtonsoft.Json_10.00.03_Install.zip in the /Install/Module folder.

The upgrade zip only contains Newtonsoft.Json_10.00.03_Install.zip in the /Install/Module folder.

I won't be able to test this right now, as I don't have that much time at the moment. I'm guessing however that the installer/upgrader won't function on the older version of Newtonsoft.Json.dll from the previous version they are attempting to upgrade.

Also, in PR #1837 the 09.02.00.SqlDataProvider file the platform is updating the assembly version of Newtonsoft.Json.dll.

Dnn.Platform/Website/Providers/DataProviders/SqlDataProvider/09.02.00.SqlDataProvider

Lines 107 to 118 in 482c35c

    
           /***** DNN-10200: update newtonsoft.json assembly to 10.0.3. *****/ 
        
           IF NOT EXISTS(SELECT 1 FROM {databaseOwner}[{objectQualifier}Assemblies] WHERE AssemblyName = 'Newtonsoft.Json.dll' AND PackageID IS NULL) 
        
           BEGIN 
        
               INSERT INTO {databaseOwner}[{objectQualifier}Assemblies] (PackageID, AssemblyName, Version) 
        
               VALUES (NULL, 'Newtonsoft.Json.dll', '10.0.3') 
        
           END 
        
           ELSE 
        
           BEGIN 
        
               UPDATE {databaseOwner}[{objectQualifier}Assemblies] 
        
                   SET Version = '10.0.3' 
        
                   WHERE AssemblyName = 'Newtonsoft.Json.dll' AND PackageID IS NULL 
        
           END

I believe if this is updated before the /Install/Module/Newtonsoft.Json_10.00.03_Install.zip, there is a chance it'll skip copying the assembly because the DB version is the same. Unless the installer is using the repair flag on the api. Again, I wasn't able to test these theory's, but hopefully it'll help someone else from @dnnsoftware/tag dig a bit deeper to see what the root cause and proper solution might be.

It looks like we need to either back out the changes to the web.config and assembly tables and handle all of that with the extension package for newtonsoft. Or remove the extension package and just include the binary in the bin directory directly and bump the assembly in the platform. It's weird right now we have a mix of both.

Any idea why this was done this way? @ashishpd @zyhfish @tpluscode

bdukes · 2018-06-14T15:09:56Z

We need to assembly to be installed via installer, rather than included in the bin/, because a difference in version can cause the site to break due to a mismatch with binding redirects. The installer will update the binding redirect at the same time as updating the file in the bin/.

I think you're right, @ohine, that updating the Assemblies row in the database would prevent the assembly file from getting copied to the bin/.

ohine · 2018-06-21T01:23:13Z

@bdukes how do you think we should solve this since v09.02.00 already updated the assembly table?

Also anyone else from @dnnsoftware/tag feel free to brainstorm as well. We only have a couple days before the codefreeze and it would be nice if we could get this item resolved before friday.

bdukes · 2018-06-21T14:34:45Z

The simple solution is to set the version to 10.0.2 via the 9.2.1 SQL script, if it's already 10.0.3, but that's going to require some good documentation to avoid confusing folks looking back on it.

That said, I don't have any other solutions that I like better. Maybe we could run some code in Upgrade.cs which does a repair install of the package, but there are timing issues we may have to contend with there.

bdukes · 2018-08-06T15:16:00Z

@ohine We're on the wrong trail here. The change you highlight was removed during testing (1829d18) and is not part of the 9.2.0 package

I don't see this issue doing an upgrade from a plain 9.1.1 site to 9.2.0, and looking at the errors on https://www.dnnsoftware.com/forums/forumid/200/threadid/542050/scope/posts it looks like Newtonsoft is just one part of it. I've tracked down the issue that caused them to install it this way: DNN-10226, but I'm not sure how this was handled with earlier Newtonsoft upgrades.

I know DnnSharp includes their own version of Newtonsoft, using the <codebase> element, and I'm wondering if there's something that doesn't work if that's in the config (which would explain why it's not an issue we're hearing more about).

ohine · 2018-08-09T01:59:22Z

@bdukes Thanks for taking the time to dig into this one a bit more. It sounds like we need to do some testing with DnnSharp next and work on reproducing the issue to see what we can do. I can get this into my schedule for the 9.3 release, I highly doubt I'd have the time for 9.2.2. If anyone else from @dnnsoftware/tag has a few extra cycles, it would be helpful to try and get this resolved in 9.2.2 if at all possible.

muddeatr · 2018-08-15T12:22:05Z

@bdukes, @ohine I'm not sure if my issue is related in any way since I haven't made it to the 9.2 update yet. I am currently on DNN 8.0.3, I updated to 8.0.4 in order to install the DnnSharp Search Boost update. Once I installed the DnnSharp update all of my ajax calls are broken. I did submit a ticket with DnnSharp but haven't heard back from them. As a side note. If I update my site from 8.0.3 to 9.2 without the Search Boost update I have no issues with any of my ajax calls, just Search Boost errors out as expected.

schotman · 2018-08-20T11:58:08Z

In my case: Upgrading from 9.1.1 tot 9.2.1 with the latest and greatest from DNNSharp results in an error installing the NewtonSoft 1.0.3. module. I had to manually copy the new dll to the bin\NewtonSoft.Json-8.0.0.0 directory and change the directive in the web.config.

When installing ActionForm (5.0.155, latest at this time) it will add the following to the web.config: < dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
< assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
< codeBase version="8.0.0.0" href="bin/NewtonSoft.Json-8.0.0.0/Newtonsoft.Json.dll" / >
< /dependentAssembly>
< dependentAssembly>
< assemblyIdentity name="dotnetnuke.log4net" publicKeyToken="53eb1fac7b60111f" / >
< codeBase version="3.0.0.0" href="bin\dnnsharp\DotNetNuke.Log4Net.dll" / >
< / dependentAssembly >
< dependentAssembly >
< assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" / >
< codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" / >
< /dependentAssembly>
< dependentAssembly>
< assemblyIdentity name="SharpZipLib" publicKeyToken="1b03e6acf1164f73" / >
< codeBase version="0.81.0.1407" href="bin\ICSharpCode.SharpZipLib.dll" / >
< /dependentAssembly>

when upgrading DNN911 to 921 it results in a incompatibility

dimarobert · 2018-08-27T14:00:23Z

@bdukes @ohine
I debugged through the upgrade process of the Newtonsoft library. Here is what I found:
The DNN manifest file has two components (in this order):

Assembly component
Config component

The installer executes the Assembly component installer that copies the newtonsoft.json.dll version 10.0.3 in bin folder and then calls AddOrUpdateBindingRedirect() which updates the web.config with the binding redirect to 10.0.3.
Then, the Config installer is executed which updates the web.config with the assembly binding once more.

The issue with DnnSharp's <codebase> assembly binding (and maybe other vendors) is in that second step of the install process. The path attribute set in the Newtonsoft package to update the binding redirect is not specific enough and doesn't take into consideration that there could be other dependentAssembly elements in web.config for newtonsoft. It targets the first ab:dependentAssembly element with @name='Newtonsoft.Json'.

In a clean DNN pre 9.2.0 the <assemblyBinding> element contains only one dependentAssembly:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>

When installing any DnnSharp module the assemblyBinding changes to:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
...
<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" />
</dependentAssembly>

After the AssemblyInstaller is executed the web.config changes to (note the order of the elements):

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" />
</dependentAssembly>
...
<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" />
</dependentAssembly>

Now it is ConfigInstaller turn to update the web.config. It searches for the dependentAssembly with path /configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name='Newtonsoft.Json'] which matches the first one (DnnSharp's one). Then it searches for the target node with /configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name='Newtonsoft.Json']/ab:bindingRedirect which matches the bindingRedirect of the second dependentAssembly (the one added earlier by AssemblyInstaller). Next it tries to remove the bindingRedirect of the second dependentAssembly from the first dependentAssembly. This throws a System.ArgumentException with message The node to be removed is not a child of this node.

Solution

I can think of two solutions:

Strengthen the path's XPath like this: /configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name='Newtonsoft.Json' and ab:bindingRedirect]. This will prevent mismatching rootNode / targetNode elements between codebase and bindingRedirect bindings. There could be other bindingRedirect bindings that could interfere with this.
Add an additional Config component before the existing one that removes all the bindingRedirects for older newtonsoft assemblies but not the codebase bindings. Then, the existing Config component will insert a bindingRedirect only if there is no bindingRedirect for version 10. There could be unforeseen issues with this approach as well.

I am willing to submit a pull request with what you think would be the best solution.
If you think that a better approach is to fix this in our modules, we (DnnSharp) are open to discussion if you think that we are the only vendor that does this.

Please let me know what your thoughts are on the matter.

bdukes · 2018-08-27T14:09:42Z

Thanks for digging into this more @dimarobert! I definitely think DNN should be able to handle the codebase redirect that y'all use.

Regarding your proposed fixes, would it work to just remove the Config component from the Newtonsoft package, since the platform is already adding the redirect correctly? Is there any reason it needs to be in both places?

If there's a reason to target the redirect via XmlMerge, I think strengthening the XPath is the right solution.

dimarobert · 2018-08-27T15:11:31Z

@bdukes For the upgrade scenario, it should be just fine if we remove the Config component. I will have to do a clean install of DNN 9.2.1 to see if there could be issues there.

From an initial check I see that there is a newtonsoft.json.dll in bin and the bindingRedirect in the web.config from the install package is diffrent from the one in the upgrade:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>

Also there is a Newtonsoft module zip in the /Install/Modules folder. If that is installed as part of the setup process then the web.config should be updated with the oldVersion="0.0.0.0-32767.32767.32767.32767" part.

EDIT: Also what is the reason for choosing that version (Version.Max)? What happens if someone needs version 11 of newtonsoft?

schotman · 2018-08-27T15:14:48Z

@bdukes

Some remarks:

when updating a dnn9.1.1 installation with DNNSharp AF installed, the installation of the newtonsoft installer package (in /install/modules) results in an error.
As a result the dll is not copied into the bin. However the assembly binding section in the web.config is changed to:

There now are two rebinding rules as mentioned by @dimarobert:

Removing the following assemblybinding:
<dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" /> </dependentAssembly>

should result in the use of the first, however the site still crashes. I assume DNN requires Newtonsoft.Json version 10.

Thus we got at least two issues:

when installing a module results in an error, web.config changes are not rolled back
installing Newtonsoft.Json as a seperate/independent module is questionable because DNN relies on it

bdukes · 2018-08-27T15:22:22Z

@schotman the entry that DnnSharp uses (with the codebase attribute) allows them to reference version 8.0.0.0 of Newtonsoft while still allowing the rest of the site to use a different version (note how the codebase path is not in the main bin folder but in a subfolder, and how it only applies to version 8.0.0.0). So, the second dependentAssembly element is for anything referencing a version other than 8.0.0.0, which is what covers DNN Platform itself, as well as any other modules.

Both entries should be able to live side-by-side, the issue appears to be related to an error that happens during upgrade because the update tries to change the bindingRedirect element of the dependentAssembly which does not have that element.

bdukes · 2018-08-27T15:26:59Z

@dimarobert the thought behind the version range used is that any component which is expecting to use Newtonsoft.Json (or any other strong-named assembly) should be able to use the installed version (i.e. the version of the file in the bin folder).

The alternative would be that .NET just refuses to run the code, because Newtonsoft.Json 10 is in the bin folder but the component was compiled against version 11.

dimarobert · 2018-08-27T17:48:49Z

@bdukes I ran a debug session on a clean install. Both the Newtonsoft upgrade step and the InstallExtensionsStep in the clean install calls the Upgrade.InstallPackage() method which does a RepairInstall of the package and the web.config ends up being the same at the end.

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
  <!--Upgraded by DotNetNuke.Newtonsoft.Json version 10.0.3 - Date: 8/27/2018 8:33:54 PM-->
  <!--<bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />-->
  <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" />
</dependentAssembly>

In both cases the bindingRedirect is updated twice. So I think that removing the Config component could be a solution.

Can you think of any other scenario for the Newtonsoft.Json zip installation?

bdukes · 2018-08-27T17:51:20Z

Nothing comes to mind, I think that's the right path forward.

dimarobert · 2018-08-29T07:04:00Z

@bdukes I've come up with another situation. If the web.config is initially in this state (in opposite order - I don't know if it could get in this state with normal use):

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
  <codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>

After the installation of the modified Newtonsoft.Json package (without the Config component) the web.config looks like this:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
<!--Upgraded by DotNetNuke.Newtonsoft.Json version 10.0.3 - Date: 8/28/2018 11:55:01 PM-->
<!--<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /><codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" /></dependentAssembly>-->
<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
  <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
  <codeBase version="8.0.0.0" href="bin\NewtonSoft.Json-8.0.0.0\Newtonsoft.Json.dll" />
</dependentAssembly>

The upgrade process completed without any issue, but do you think that this could be an issue in the future?

This XPath expression would find any matching <dependentAssembly> element, whether it had a <bindingRedirect> or a <codeBase> element For dnnsoftware#2121

bdukes · 2018-08-29T13:47:12Z

@dimarobert I don't think that'll cause any major issues, but we should be able to resolve the ambiguity and fix this issue for good. I've pushed a change to your PR which I believe should do that.

Tychodewaard · 2018-10-30T20:08:58Z

Kinda lost here...I just upgraded a small site from 804 to 922. I figured this issue would be solved in 922. But unfortunately not: see error below.
Any suggestions what my next step should be or how to solve this?

[FileLoadException: Could not load file or assembly 'Newtonsoft.Json' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] [FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0 System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +36 System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +152 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) +77 System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +21 System.Reflection.Assembly.Load(String assemblyString) +28 System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +38 [ConfigurationErrorsException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +738 System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() +217 System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) +130 System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) +170 System.Web.Compilation.BuildManager.GetPreStartInitMethodsFromReferencedAssemblies() +92 System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded) +290 System.Web.Compilation.BuildManager.ExecutePreAppStart() +157 System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +549 [HttpException (0x80004005): Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +10074636 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +95 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +254

sleupold · 2018-10-30T20:11:16Z

did you clear local browser cache?

Tychodewaard · 2018-10-30T20:13:20Z

No need, uptimerobot also sees the website is down. You can check http://www.bydaans.nl/ yourself

bdukes · 2018-10-30T20:15:18Z

Your web.config should only have one dependentAssembly for Newtonsoft.Json that has a bindingRedirect inside it (rather than a codeBase), and the newVersion attribute in that should match the version in the bin/, probably it should be this:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
  <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0.0" />
</dependentAssembly>

Tychodewaard · 2018-10-30T20:31:59Z

I deleted some and kept:
  <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.0" /> </dependentAssembly>

This did not change the error.

As it says in the comments, DNN upgraded to 10..3, I changed the web.config to:
  <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-32767.32767.32767.32767" newVersion="10.0.3" /> </dependentAssembly>

This created another error but that is probably related to a module, so...I think I can move on...

ohine added the Type: Bug label Jun 14, 2018

ohine added this to the 9.2.1 milestone Jun 14, 2018

ohine modified the milestones: 9.2.1, 9.2.2 Jul 24, 2018

ohine modified the milestones: 9.2.2, 9.3 Aug 21, 2018

dimarobert mentioned this issue Aug 27, 2018

Fix Newtonsoft.Json package install during DNN Upgrade. #2271

Merged

bdukes added a commit to dimarobert/Dnn.Platform that referenced this issue Aug 29, 2018

Only update/remove binding redirects

e15318f

This XPath expression would find any matching <dependentAssembly> element, whether it had a <bindingRedirect> or a <codeBase> element For dnnsoftware#2121

mitchelsellers closed this as completed in #2271 Sep 14, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NewtonSoft #2121

NewtonSoft #2121

doodlleus commented Jun 14, 2018

mitchelsellers commented Jun 14, 2018

doodlleus commented Jun 14, 2018 via email

ohine commented Jun 14, 2018 •

edited

Loading

bdukes commented Jun 14, 2018

ohine commented Jun 21, 2018

bdukes commented Jun 21, 2018

bdukes commented Aug 6, 2018

ohine commented Aug 9, 2018

muddeatr commented Aug 15, 2018 •

edited

Loading

schotman commented Aug 20, 2018 •

edited

Loading

dimarobert commented Aug 27, 2018 •

edited

Loading

bdukes commented Aug 27, 2018

dimarobert commented Aug 27, 2018 •

edited

Loading

schotman commented Aug 27, 2018

bdukes commented Aug 27, 2018

bdukes commented Aug 27, 2018

dimarobert commented Aug 27, 2018 •

edited

Loading

bdukes commented Aug 27, 2018

dimarobert commented Aug 29, 2018 •

edited

Loading

bdukes commented Aug 29, 2018

Tychodewaard commented Oct 30, 2018

sleupold commented Oct 30, 2018

Tychodewaard commented Oct 30, 2018

bdukes commented Oct 30, 2018

Tychodewaard commented Oct 30, 2018 •

edited

Loading

NewtonSoft #2121

NewtonSoft #2121

Comments

doodlleus commented Jun 14, 2018

mitchelsellers commented Jun 14, 2018

doodlleus commented Jun 14, 2018 via email

ohine commented Jun 14, 2018 • edited Loading

bdukes commented Jun 14, 2018

ohine commented Jun 21, 2018

bdukes commented Jun 21, 2018

bdukes commented Aug 6, 2018

ohine commented Aug 9, 2018

muddeatr commented Aug 15, 2018 • edited Loading

schotman commented Aug 20, 2018 • edited Loading

dimarobert commented Aug 27, 2018 • edited Loading

Solution

bdukes commented Aug 27, 2018

dimarobert commented Aug 27, 2018 • edited Loading

schotman commented Aug 27, 2018

bdukes commented Aug 27, 2018

bdukes commented Aug 27, 2018

dimarobert commented Aug 27, 2018 • edited Loading

bdukes commented Aug 27, 2018

dimarobert commented Aug 29, 2018 • edited Loading

bdukes commented Aug 29, 2018

Tychodewaard commented Oct 30, 2018

sleupold commented Oct 30, 2018

Tychodewaard commented Oct 30, 2018

bdukes commented Oct 30, 2018

Tychodewaard commented Oct 30, 2018 • edited Loading

ohine commented Jun 14, 2018 •

edited

Loading

muddeatr commented Aug 15, 2018 •

edited

Loading

schotman commented Aug 20, 2018 •

edited

Loading

dimarobert commented Aug 27, 2018 •

edited

Loading

dimarobert commented Aug 27, 2018 •

edited

Loading

dimarobert commented Aug 27, 2018 •

edited

Loading

dimarobert commented Aug 29, 2018 •

edited

Loading

Tychodewaard commented Oct 30, 2018 •

edited

Loading