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 
If your plugin requires Json, I’d recommend adding your own reference rather than the one included with ARC. The bug doesn’t apply to what it’s being used for ATM.
Removing requiring assistance
@DJ,
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 ?
Oh strange - because the libraries have different version identifiers, they shouldn’t cause conflict in the gac. For example your ibm Watson plugin loads a different version of naudio than what’s included in ARC install. Wonder why that doesn’t apply to json?
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.
I didn't had the opportunity to check the 3 rd party library, but if you reference without a specific version or maybe some lazyload.
Have your plugin include its own json dll and don’t reference the one in ARC. I’ll update ARC json for the next release in a in December.
Does not work, i tried that. My plugin has the last version (11.0) I created some dummy code to reference the newtonjson and force loading my assembly, mine is loaded.
Once i use a method from 3rd party library, the ARC version is loaded.
The only way is to remove the ARC's version.
Crazy - that’s two issues to resolve on our end then. The fact that json is somehow owning the namespace in the gac for all versions and the version needs to be updated.
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?
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.
That doesn’t answer the question of why naudio can be used in your ibm Watson plugin even though it’s in ARC.
It's a direct reference.
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.
That’s how I assumed it worked when I wrote the assembly resolver code - but I thought differently when I saw your ibm Watson plugin including its own naudio. Why does your ibm Watson plugin have its own naudio if it’ll use the version provided with ARC?
I noticed your naudio version is "customized":
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!
If both naudio assemblies are loaded, and yours is used by your plugin... is it used because the versions are different?
Why wouldn’t that be the case with json?
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.
I already did the json update for the next release. I’ll have to look into it more to understand if there’s a way for the namespaces to be identified by their versions in the resolver