Since version 2.6, EPLAN API assemblies are shadow copied, i.e. during registration they are stored into temporary folder, and loaded from there.
The benefit of shadow-copy technique is that original assemblies are not locked so newer versions can be distributed via a network share even when are currently used by another workstations.
This concerns both addons and addins.
The whole addon's bin directory with subdirectories will be copied to the user application roaming directory (%appdata%\EPLAN\ShadowCopyAssemblies\Process-ID\Addon-Name).
So all files (*.dlls, *.xml etc.) and all bin subdirectories (language subdirectories etc.) are also copied. This is done when EPLAN starts and an addon is registered or when an addon is manually registered from Addons dialog.
Eplan will load addon's assemblies from the shadow directory and not from the original addon directory. So an addon could be updated without the need to stop all Eplan instances using the addon.
If an addin is loaded by Eplan start or via "API"->"Manage" option, it will be copied to a shadow directory (%appdata%\EPLAN\ShadowCopyAssemblies\Process-ID\).
Eplan keeps the original addin path for further assembly resolving. This means, if an addin references other assemblies from the addin original path, these referenced assemblies will be found.
After resolving they will be copied to the shadow directory. The problem could be referencing data from other directories using a relative path to the original addin directory.
As a solution, there was created IEplAddInShadowCopy interface allowing getting original path of an addin.
In addition, conflicts can arise when multiple Addins / Addons projects in a solution refer to an assembly with a namespace and class of the same name, but different versions. The following scenario should be considered: For example, if you use the "Write" library of version 1.0.0 in one project (Project1) and the "Write" library of version 2.0.0 in the other project (Project2), this will lead to unwanted behavior in your solution.
Depending on which project - be it Project1 or Project2 - you call first, it will be executed correctly and will reference the correct library. If you then execute the other project, it will reference the previous library, the first version executed.
The work around this behavio, sign the library versions independently of each other. You can then use the library with different versions at will.
Through the signing the library receives a specific key token or "Strong name" which supports to distinguish the libraries.
