Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
Asked — Edited

Please Update ARC Desktop Third Party Library


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


Upgrade to ARC Pro

Harnessing the power of ARC Pro, your robot can be more than just a simple automated machine.

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

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?


Unfortunately with the number of users, we have to limit updates to monthly.

Ok, I'll wait for the next update.


Crazy - that’s two issues to resolve on our end then.

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


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.


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


[assembly: AssemblyProduct("EZ-Robot Modified NAudio")]
[assembly: AssemblyCopyright("© 2001-2012 Mark Heath")]

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.


Why does your ibm Watson plugin have its own naudio if it’ll use the version provided with ARC?

Sorry, this is a two answer questions.


if it’ll use the version provided with ARC?

You skip my post...
Versions are different. Both are loaded, and mine is used.

I dump all loaded assemblies (Watson plugin):


mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
ARC, Version=2015.8.9.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Windows.Forms, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Drawing, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Configuration, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Xml, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
EZ_B, Version=2015.7.28.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
System.Speech, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Windows.Forms.Ribbon, Version=, Culture=neutral, PublicKeyToken=b3424d4528a585a6
PresentationCore, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
WindowsBase, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Alsing.SyntaxBox, Version=2015.5.15.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.VisualStudio.DesignTools.WpfTap, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
PresentationFramework, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Xaml, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Runtime.Serialization, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
SMDiagnostics, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.ServiceModel.Internals, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
CefSharp.Core, Version=, Culture=neutral, PublicKeyToken=40c4b6fc221f4138
CefSharp, Version=, Culture=neutral, PublicKeyToken=40c4b6fc221f4138
CefSharp.WinForms, Version=, Culture=neutral, PublicKeyToken=40c4b6fc221f4138
System.Web.Services, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
FFMPEG, Version=2013.8.13.0, Culture=neutral, PublicKeyToken=0c913eb082202b8e
Accessibility, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Design, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.ComponentModel.DataAnnotations, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Web.ApplicationServices, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
UIAutomationProvider, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.ServiceModel, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
Microsoft.GeneratedCode, Version=, Culture=neutral, PublicKeyToken=null
Microsoft.GeneratedCode, Version=, Culture=neutral, PublicKeyToken=null
aForge, Version=2015.7.6.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
EZ-QRCode, Version=2015.4.29.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
NAudio, Version=2015.4.29.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9
Microsoft.GeneratedCode, Version=, Culture=neutral, PublicKeyToken=null
Watson.EZPlugin, Version=, Culture=neutral, PublicKeyToken=null
Newtonsoft.Json, Version=, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
ARC.Plugin.Common, Version=, Culture=neutral, PublicKeyToken=e2222d758e8196fc
EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Net.Http, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
WindowsFormsIntegration, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
PresentationFramework.Aero2, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.GeneratedCode, Version=, Culture=neutral, PublicKeyToken=null
CredentialManagement, Version=, Culture=neutral, PublicKeyToken=null
System.Net.Http.Formatting, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Data.SQLite, Version=, Culture=neutral, PublicKeyToken=db937bc2d44ff139
System.Transactions, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Data.SQLite.EF6, Version=, Culture=neutral, PublicKeyToken=db937bc2d44ff139
System.Data.Entity, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
EntityFramework.SqlServer, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
Anonymously Hosted DynamicMethods Assembly, Version=, Culture=neutral, PublicKeyToken=null
System.EnterpriseServices, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Xml.Linq, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
EntityFrameworkDynamicProxies-EntityFramework, Version=, Culture=neutral, PublicKeyToken=null
EntityFrameworkDynamicProxies-Watson.EZPlugin, Version=, Culture=neutral, PublicKeyToken=null
NAudio, Version=, Culture=neutral, PublicKeyToken=null
System.Numerics, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

NAudio, Version=2015.4.29.0, Culture=neutral, PublicKeyToken=c3a3457c97d352d9

and mine:
NAudio, Version=, 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?


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