ptp
USA
Asked
— Edited
@DJ,
Q)
Can you please update the ARC Desktop's Newtonsoft.Json assembly aspa ?
Current version is 9.x and contains a nasty json bug.
It seems (guessing) is only used with the Nest control.
Please 
Removing requiring assistance
You should know that if i asked that, is because i hit a wall otherwise i don't bother you with obvious stuff.
Let me explain my plugin requires a third party library, that library references Newtonsoft.Json.
When you load a library the preference goes to existent libraries (Ez-builder) so I don't have a way to influence loading a new library version.
If i replace the ARC's library with a recent version (11.0), it works as expected.
If i remove the ARC's library the loading process will be handled by ARC Resolve assembly then it checks the plugin folder for a version.
Do you see another way of solving the issue without you updating or removing the library ?
Sure you’re not adding a reference to the json dll in ARC folder? Add your own json dll to your plugin project.
I will update json on ARC in the next release, that won’t be for another few weeks.
Once i use a method from 3rd party library, the ARC version is loaded.
The only way is to remove the ARC's version.
Unfortunately with the number of users, we have to limit updates to monthly.
Is the feature you require in the json library affected by the security bug?
Ok, I'll wait for the next update.
The way the plugin framework is implemented, ARC references (Application Domain) will have precedence over third party assembly locations (plugins)
The only way to solve is to externalize non relevant core modules e.g. Nest control uses Newtonsoft. If Nest control is converted to a Plugin, you can move the Newtonsoft to the plugin folder and remove the ARC reference.
That applies to all external libraries, If you can't or you don't don't want to do it.
Updating all the ARC assemblies to the last version, allows the plugins to control/load older versions to accommodate plugins external versions.
Scenario:
ARC references Util.dll v3.0.
Plugin 1)
References Util.dll v.4.0, ARC version (3.0) does not satisfy the assembly reference load process.
ARC (CurrentDomain.AssemblyResolve) looks for a Util.dll inside the plugin folder and if finds loads the assembly and returns the reference.
So ARC skill plugin framework looks for Util.dll and loads it does not care the version is 4, 2, 10.
Let's complicate the things.
Plugin 2)
References: Util.dll v.5.0
SuperUtil.dll -> references -> Util.dll v.4.0
This is perfect possible but from a logistic perspective you can only have one Util.dll in the plugin folder.
But that is the plugin limitation not a framework limitation.
So which version should you copy to the plugin folder ?
I will downgrade my plugin version to 4.0 and now my plugin and SuperUtil.ll use the same Util.dll version.
This works, but imagine that v.4.0 has bug and i know v.5.0 has been fixed.
So if i keep my plugin pointing to v.5.0 it works why ?
CurrentDomain.AssemblyResolve is called to solve the plugin reference Util 5.0 and it loads the plugin dll from the plugin folder.
Then it's called from to solve Util 4.0 and CurrentDomain.AssemblyResolve loads the plugin dll Util 5.0 (only one dll) and returns the assembly.
This behavior is similar to Runtime/bindingRedirect if the new version 5.0 does not break method signatures the SuperUtil will work with 5 version instead of 4.0 version.
BUT
Plugin 3)
References: Util.dll v.5.0
SuperUtil.dll -> references -> Util.dll v.3.0
CurrentDomain.AssemblyResolve is called to solve the plugin reference Util 5.0 and it loads the plugin dll from the plugin folder.
but when SuperUtil.dll references Util 3.0 CurrentDomain.AssemblyResolve is not called because ARC has a direct reference to the Util 3.0, the framework will load the ARC Util.dll 3.0 version and AssemblyResolve is never called.
What happen if ARC has the newest version Util 10.0 ?
CurrentDomain.AssemblyResolve is called and then is up to the plugin to solve the issue.
Code:
So i don't know if is specific for EZ-Robot use, if the code is maintained after or not, If i found an issue is NAudio or ARC responsibility ?
Also if you change the library (version) in the future, my plugin maybe or maybe not break.
So if i'm going to be responsible for maintaining the plugin, I need to know the dependencies and upgrade the libraries for bug fixes.
The only thing i can't control is when specific library old version is loaded by ARC or by another plugin and my plugin uses a third library referencing that same old library.
If this happens and is a plugin i can avoid using the other plugin, but if is ARC i can't avoid the old dll being loaded.
Sorry, this is a two answer questions.
You skip my post...
Versions are different. Both are loaded, and mine is used.
I dump all loaded assemblies (Watson plugin):
yours:
NAudio, Version=2015.4.29.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
and mine:
NAudio, Version=1.8.4.0, Culture=neutral, PublicKeyToken=null
both loaded in same domain!
Why wouldn’t that be the case with json?
Yes
I explained what happens with multiple versions and dependencies.
I did a little bit more research on the third party library and it seems there are at least two other assemblies referencing different json versions.
Unfortunately one of those 3rd party references the same ARC version (9.0), ARC is a direct version match, ARC reference is loaded (although is not loaded unless you add the nest control but is in the ARC folder).
So the problem becomes more complicated when other versions are loaded from the plugin folder.
The application domain ends up with 2 versions loaded, why is that different from 2 Naudio versions ?
Binary Serialization is based on binary references one component references ARC version, another sub component references the plugin version.
If you exchange object instances between sub-components crashes because they are from different assemblies.
I worked and built plugin/addins modules, and there are some design issues, and some issues are more complex to solve.
I don't want to push a component upgrade. I only mentioned (from my POV) because it seemed simple.
I'll try to explore other options.