Since version 2.6, EPLAN API assemblies are shadow copied, i.e. they are saved in a temporary folder during registration and loaded from there.
The benefit of the shadow copy technique is that the original assemblies are not locked, so that newer versions can be distributed via a network share even if they are currently being used by other workstations.
This applies to both add-ons and add-ins.
The entire bin directory of the add-on with its subdirectories is copied to the user application roaming directory (%appdata%\EPLAN\ShadowCopyAssemblies\Process-ID\Addon-Name).
This means that all files (*.dlls and *.exe) and all bin subdirectories (language subdirectories, etc.) are also copied. This is done when EPLAN is started and an add-on is registered or when an add-on is registered manually from the Add-ons dialog.
EPLAN loads the assemblies of the add-on from the shadow directory and not from the original add-on directory. This allows an add-on to be updated without the need to stop all EPLAN instances using the add-on.
When an add-in is loaded by EPLAN start or via API > Manage option, it is copied to a shadow directory (%appdata%\EPLAN\ShadowCopyAssemblies\Process-ID\).
EPLAN keeps the original add-in path for further assembly resolving. This means that 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, IEplAddInShadowCopy interface was created, which allows to get the original path of an add-in.
In addition, conflicts can arise when multiple add-in / add-on 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 is executed.
To work around this behavior, sign the library versions independently of each other. You can then use the library with different versions at will.
Signing gives the library a specific key token or "strong name" that helps distinguish the libraries.
