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.
Update for VS 2017: To run fuslogvw.exe, run the Developer Command Prompt for VS 2017 as an administrator, type fuslogvw, and press Enter.
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. The reports are in the Default directory of the log directory you specified above. In the Default directory, find the va_ecl.exe directory: that's Eclipse. Look for the file with the assembly name that's causing you problems and open it. If the loading fails, you may be able to tell why (the log is a bit cryptic).
In one case I ran into, Eclipse was looking for the assembly (OxyPlot) in its application directory rather than where my script was located. The reason was that the assembly was not being loaded by my script. It was being loaded by the PresentationFramework assembly (this is the WPF assembly). I deduced that it was because XAML encountered a class in OxyPlot for the first time. To solve the problem, I created a dummy OxyPlot object before any XAML could encounter it.
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.
留言