If you run your binary plug-in script in Eclipse, and later on (in the same session) you try to run a different version of the same script, the second one will not run. Eclipse will simply run the first script again. In some cases, Eclipse will crash.
Similarly, if you have a class library that your scripts depend on, and different scripts use different versions of your library, only the version of the library that was loaded first will be used throughout the Eclipse session. Again, Eclipse may crash.
The different versions of your scripts or libraries (assemblies) have the same name, so the .NET assembly loading mechanism thinks they’re all the same. This wouldn’t happen if your assemblies were strongly named because strong-naming an assembly uniquely identifies a specific version of the assembly. However, the ESAPI assemblies that your scripts depend on are not strongly named, which prevents you from strong-naming your own assemblies.
The best solution would be to strong-name your assemblies (scripts and libraries), but as I mentioned, this is not currently possible. Varian is actually working on strong-naming the ESAPI assemblies, so at least it will be possible soon.
In the meantime, you can name each version of your assembly differently. For example, you can append the version of the assembly to its basic name. If your assembly is named CoolScript.esapi, you can rename it to CoolScript-18.104.22.168.esapi. It’s not enough to simply change the assembly’s file name. You need to go into the properties of your assembly and change its name there, then re-compile.
This solution is not perfect. You need to remember to change the name of your assembly every time you change its version. If you have lots of scripts and libraries, that’s a lot to remember.
Even if all your assemblies were strongly named and thus .NET can load different versions of them at the same time, this is actually not recommended.
Wouldn’t it be nice to be able to unload all the assemblies related to a script after running it? That way, you can run a different script and it wouldn’t conflict with a previous one. This would only be possible if Eclipse isolated each plug-in script into its own AppDomain, but it doesn’t. Eclipse loads all scripts into the default AppDomain. And once an assembly is loaded into an AppDomain it cannot be unloaded.
Hopefully, a future version of Eclipse will load its plug-ins into their own AppDomains.