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 add-ons and add-ins.
The whole add-on'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 add-on is registered or when an add-on is manually registered from Add-ons dialog.
Eplan will load add-on's assemblies from the shadow directory and not from the original add-on directory. So an add-on could be updated without the need to stop all Eplan instances using the add-on.
If an add-in 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 add-in path for further assembly resolving. This means, if an add-in references other assemblies from the add-in 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 add-in directory.
As a solution, there was created IEplAddInShadowCopy interface allowing getting original path of an add-in.
In addition, conflicts can arise when multiple Add-ins / Add-ons 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.
