Restarting Eclipse at every compilation and un-deletable DLL plugin file

Apr 16, 2015 at 8:27 AM
Hi all,

I've noticed that the first compiled plugin to be run cannot be overwritten until Eclipse is entirely closed. This is annoyance number one but there's worse :
have to restart Eclipse every time I modify my source code and recompile. If I don't do that, I find that the plugin is not updated, even if it is saved under a different name.
There seem to be some sort of confusion within the script loader that functions in different files with the same name are not updated in the memory or something.

Am I the only one in this situation ? Is there a way around this ? Having to restart Eclipse and load a test patient for every tiny modification to the script is a massive annoyance and slows down development very significantly.

Thanks !
Apr 16, 2015 at 11:25 AM

Hi Julien,

Unfortunately there's no way around this. What we do to avoid this is run our scripts using a standalone script that plays the part of Eclipse; you can open your patient and select one or more plans to send to the script. This has the added benefit that allows you to debug your script with Visual Studio's debugger.

The standalone script is called PluginTester, and I uploaded the project with sample test script to the code section. Feel free to download it and try it out.

Eduardo

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

Apr 16, 2015 at 11:43 AM
Excellent idea Eduardo, thanks for the tip. To be honest, I hadn't understood what the plugin tester was about until I read your reply.
Coordinator
Apr 16, 2015 at 4:43 PM
Another option would be to change the assembly name in the properties->Application tab of the plug-in project. Something like MyFirstScript.esapi -> MyFirstScript_1.esapi. Doing this allows you to recompile and re-launch the script from Eclipse.
Coordinator
Apr 16, 2015 at 6:50 PM
The problem is compounded if your script depends on shared libraries that you've created. These are loaded once by Eclipse, and if another script requires a different version of the shared library, Eclipse doesn't load it. The "hacky" solution is to rename all your shared library assemblies as well as your script assembly (as stuomaal suggested). Some of these problems should go away once Varian strongly names their DLL's (I believe this is happening in a future release). But another problem is that Eclipse seems to load scripts into its current AppDomain, which then becomes impossible to unload them (which is why you can't even replace your script DLL with a new one once you run it). It would be better if Eclipse created a new AppDomain, loaded the script there, and then deleted the AppDomain once the script was exited. This would cause all assemblies in that AppDomain to be unloaded as well.
Apr 17, 2015 at 10:08 AM
Thanks everyone for your input.

It's odd because the simple renaming of the dll doesn't seem to be enough to fool Eclipse into thinking this is a different plugin. Anyway, I realise now that it's a problem that has deep-rooted causes and that I have to put up with it.

Cheers,

J.
Coordinator
Apr 20, 2015 at 4:09 PM
Eclipse is loading assemblies in the given folder, not file names. So the file name trick doesn't work. I have a way more fun solution to this problem. I call it "CrashMe.Esapi".
namespace VMS.TPS
{
  public class Script
  {
    public Script()
    {
    }

    public void Execute(ScriptContext context /*, System.Windows.Window window*/)
    {
        var crash = new CrashScripty();
        //Crash Eclipse
        var user = crash.CurrentUser;
    }
  }

  public class CrashScripty : VMS.TPS.Common.Model.API.Application
  {
      public CrashScripty() : base() { }
  }
}
Just run this and all of your problems will be solved quickly. This crashes Eclipse, launches User home, and is one click away from a full reboot. Releases all dlls.
Coordinator
Apr 8, 2016 at 5:13 AM
I've expanded my comment in the following blog post: http://www.carlosjanderson.com/version-conflicts-in-esapi-scripts/