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