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?
