As I mentioned in Version Conflicts in ESAPI Scripts, Eclipse loads all of your scripts and shared libraries into the default AppDomain. This means that if try to run two versions of the same script (in the same Eclipse session), Eclipse will complain or crash.
As you’re trying to debug issues like these, it would be helpful to know exactly which assemblies Eclipse has loaded. Eclipse actually provides this information, although it’s well-hidden. In Eclipse, click on the Help button, then on About External Beam Planning, then on More Info, then on OS System Info, then expand Software Environment, and select Loaded Modules.
Among the 300+ entries in the list are your script assemblies (and any dependent assemblies), if Eclipse has loaded them successfully. For some reason, at least for me, it just shows the name and the location of the assembly, even though there are columns for the version and date of the assembly. Still, the information provided may help you figure out which assemblies are and are not actually loaded.
Occasionally, you may have run into an issue where Eclipse can’t find an assembly that your script depends on. Yet, it’s there, in the same directory as your script. To figure out what’s going on, you’ll need a better tool: fuslogvw.exe.
Fuslogvw.exe logs the process that an .NET application takes to load an assembly. If any assembly failed to load, it’ll show you why.
If you’ve installed Visual Studio, you probably already have fuslogvw.exe. In my computer, it’s located in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64. For some reason, in the Windows directory, I have several other directories (e.g., v8.0A, v10.0A). Make sure you go to the correct directory. If you’re running Windows 7, go to the v7.0A directory.
In Windows Explorer, navigate to the location of fuslogvw.exe, then right-click on it and select Run as administrator. Click on Settings, then select Log all binds to disk, and check Enable custom log path. Type in a temporary directory, such as C:\Temp, and click OK. Restart your computer.
Now, any time a .NET application tries to load an assembly (including Eclipse) you’ll be able to see a log report of the process. If the loading fails, you’ll be able to tell why. In one case I ran into, Eclipse was looking for the assembly in its application directory rather than where my script was located.
Note that for fuslogvw.exe to log Eclipse assembly loading events, it needs to run on your computer, not Citrix. One can probably turn on logging on Citrix, but administrator privileges are needed.
Finally, don’t forget to disable logging after you’re done. If you leave it on, it’ll continue to write information to files, which may slow down your computer.