Collision of Add-Ins in ArcGIS Pro

Question

I've been developing several add-ins (6 at this count) and loading them into a custom tab. In a few cases I've taken one add-in and Forked it and to create a new add-in with similar functionality.

Is there a risk doing this? For example: (1) if I have a public variable within one add-in,  is it visible from other add-ins, (2) if I had a public class could another add-in access that class 'across' add-ins, and (3) if I had two public variables, or classes, in two add-ins with the same names could there be a Collision resulting in an error in one or more of the add-ins?  Other way to ask this this, are add-ins thread safe containers?

danielri · Answer

Found an additional risk with multiple add-ins

Implement AssemblyLoadContext for Add-In Isolation... - Esri Community

danielri · Answer

Some deep thoughts :-). Sounds like if one obtained an instance of a tool that had autoLoad="true" in the config.daml  you could use FrameworkApplication.DockPaneManager.Find(<My Tool>) to obtain the instance of the tool and then you should be able to get/set parameters -assuming the tool had defined methods in the default class that is defined in the config.daml.

At one point I was attempting to add thread level error checking (ErrorHandler_UIThreadException) to add-in #5 in load sequence and at run-time I received an error saying something along the lines of "unable to redefine error handler, one already exists in add-in #1". This public variable also caused a conflict: public static bool CheckForIllegalCrossThreadCalls = false;

CharlesMacleod · Answer

there's a lot to unpack here.

To reference any property or method on any class at compile time u must have a reference to the assembly that defines "that class" in your .csproj (unless u r using reflection which i assume u r not).

Without a reference to "that" particular addin assembly in the "other" addin .csproj (which would be strange but there is nothing to prevent it) then references to classes or properties within it in your source code would never compile.

If you _do_ add a reference to another addin assembly to your addin then the usual rules of .NET will apply - any objects sharing the same name within the scope of a given method or routine would end up needing to be fully-qualified to avoid naming collisions and the compiler will prompt u as such when u attempt to compile..

There is no concept of a "global variable" within Pro at runtime. U can, however, always access running instances of particular objects instantiated by the Framework via the various FrameworkApplication.FindModule, GetPluginWrapper, FrameworkApplication.DockPaneManager.Find(...) calls but u wld still need references to the various assemblies to reference public content (assuming u were not using reflection) unless they were defined on the base "Contract" classes they inherit from

@RichardDaniels wrote:I've been developing several add-ins (6 at this count) and loading them into a custom tab. In a few cases I've taken one add-in and Forked it and to create a new add-in with similar functionality.

Is there a risk doing this? For example: (1) if I have a public variable within one add-in,  is it visible from other add-ins, (2) if I had a public class could another add-in access that class 'across' add-ins, and (3) if I had two public variables, or classes, in two add-ins with the same names could there be a Collision resulting in an error in one or more of the add-ins?  Other way to ask this this, are add-ins thread safe containers?