Why I Don’t Use the Eclipse Script Wizard

The Eclipse Script Wizard is a program that allows you to easily create single-file plug-ins, binary plug-ins, and stand-alone apps based on ESAPI. (For tips on when to use each type of script, see my blog post Single-File Plug-In vs. Binary Plug-In vs. Stand-Alone App). The wizard comes with your ESAPI installation, and the ESAPI Reference Guide explains how to use it.

Although it’s fine for getting started with ESAPI, I don’t recommend using the wizard for “real” scripts. The main reasons are that it doesn’t organize your files properly and it doesn’t create Visual Studio solutions—it only creates projects.

Bad File Organization

For a single-file plug-in, the wizard puts the C# file into a shared Plugins directory (a.k.a. folder). This means that all single-file plug-ins created by the wizard are thrown into the same directory.

This file organization is terrible for version control. You’re forced to using a single repository for all your scripts. This is a bad idea because your commit history will contain commits from different scripts. Not only is this confusing to you and to others working on different scripts, but managing the history for any one script will be a nightmare.

For binary plug-ins, the wizard does a similar thing: it puts the binary files (the DLLs) into the same Plugins directory as the single-file plug-ins. The source files are in their own directory at least, so you’re able to have separate version control repositories for each binary plug-in.

The only benefit with putting everything into one directory is that you won’t have to browse your file system to find the script in the Eclipse launcher. Of course, it would be even better to have a smarter script launcher that allows you to keep your scripts in their own directories yet doesn’t make you hunt for them.

No Solutions

For any script type—single-file plug-in, binary plug-in, or stand-alone app—the script wizard does not create a Visual Studio solution. It only creates a project.

However, projects are incomplete without a solution. In fact, when you create a new Visual Studio project you’re actually creating a solution with one project. If you try to save a project by itself, Visual Studio asks you to create a solution for it.

Creating Scripts Manually

For the reasons above, I prefer to create script projects in Visual Studio manually. The ESAPI Reference Guide has instructions on how to manually create each script type. I’ll summarize those steps here.

To create a single-file plug-in script, open Visual Studio and go to File → New → Project. Choose “Class Library” and name the project (and optionally, the solution). Add references to PresentationFramework, PresentationCore, WindowsBase, and System.Xaml. Also add references to the ESAPI libraries: VMS.TPS.Common.Model.API and VMS.TPS.Common.Model.Types, located at C:\Program Files (x86)\Varian\Vision\13.6\Bin64\esapi\. Change the project “Platform target” to “x64”. Rename the main C# file to the name of your script and replace the contents of the file with the following:

(If you’re not going to use the Window, you can leave out that parameter.)

To create a binary plug-in script, follow the same steps as single file plug-in. (This is a benefit of creating your own solutions: it’s easy to turn a single file plug-in into a binary plug-in.) Then, open the project’s properties and go to the Application section; add “.esapi” to the Assembly name. I recommend that you use EclipsePlugInRunner to test your scripts (see my blog post Run and Test Plug-In Scripts from Visual Studio).

To create a stand-alone app, create an executable project (like WPF or Console) and reference the ESAPI libraries. At some point in your program you’ll need to create the ESAPI Application object, which you can use to open (and close) patients:

Stand-alone apps can be launched like a regular program, but this may be difficult if you’re behind a Citrix system. For a solution, see my blog post Launch Stand-Alone Apps from Eclipse.

2 thoughts on “Why I Don’t Use the Eclipse Script Wizard

  1. Matthew Schmidt

    Hi Carlos,

    I completely agree with you that creating projects for more advanced scripts using Visual Studio instead of the Eclipse Scripting Wizard is preferable. I think you make a great point about version control; that becomes much more important as you try to become a more serious programmer. I generally create all my programs as if they were a stand-alone executable, and if I see fit (i.e. the script only targets a single patient, or context information) I’ll convert it to a plug-in later. Do you see any issue with this? Also, interesting choice of “class library” for single-file projects. I’ve been looking into those for building my own pseudo libraries for things like gamma calculations.

    Reply
    1. Carlos Anderson Post author

      Hi Matt,

      I haven’t tried it, but I can’t think of any major issues with converting a stand-alone app into a plug-in. The one thing I can think of right now is App.config. A stand-alone app will use its own App.config file for its settings, but a plug-in tends to use Eclipse’s App.config. I’ve had to play some tricks to get a plug-in to read its own App.config, and in some cases I’ve given up and created my own settings file.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *