top of page

An Easy Way to Launch Stand-Alone Apps from Eclipse

In a previous post (Launch Stand-Alone Apps from Eclipse), I discussed how to implement a plug-in script that can launch any stand-alone app. This is helpful because stand-alone apps can't be launched from Eclipse directly (only plug-in scripts can).

The method I described in that post works well, but it's still somewhat complex. It requires a separate text file to keep track of the available stand-alone apps. It also shows a dialog box with the apps to choose from, so there's an extra step before launching the desired app.

I found a way to launch stand-alone apps from Eclipse that is identical to launching plug-in scripts. You can even put them in the Tools menu, just like plug-in scripts. In this post, I'll show you how to do this.

The idea is to create a separate project in your Visual Studio solution, and that project will act as a plug-in script. It's only job is to find the actual stand-alone app (an executable file) and launch it.

First, in your stand-alone solution add a new class library project. If your main project is called "MyApp," you can name the new project "MyApp.Script." In the solution explorer, right-click on the project and rename the assembly to "MyApp.esapi" (of course, start with the name of your main project, but plug-in script assemblies must end with ".esapi").

Add references to the Varian assemblies (VMS.TPS.Common.Model.API and VMS.TPS.Common.Model.Types). Also, add a reference to the PresentationFramework (in the Assemblies section), which we'll need for showing a message box.

Open the automatically created Class1.cs file and rename it to Script.cs (it doesn't have to be this name, but it's what I like to name my main plug-in script class). Replace the contents of this file to the following:

using System;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Windows;
using VMS.TPS.Common.Model.API;

namespace VMS.TPS
    public class Script
        public void Execute(ScriptContext context)
            catch (Exception)
                MessageBox.Show("Failed to start application.");

        private string AppExePath()
            return FirstExePathIn(AssemblyDirectory());

        private string FirstExePathIn(string dir)
            return Directory.GetFiles(dir, "*.exe").First();

        private string AssemblyDirectory()
            return Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

As you can see, the code uses Process.Start to launch the application. The path of the application is assumed to be the first executable file in the directory where this script is located. This is not true, yet, but we'll fix that next.

Finally, reference the plug-in script project from your main stand-alone project. This will cause the build system to copy the plug-in script files to the same directory as your stand-alone files.

Now, in Eclipse you should be see "MyApp.esapi.dll" when you choose your stand-alone's directory in the Scripts dialog box. When you run it, it will immediately launch your app. The plug-in script ends as soon as the stand-alone app is launched, so you'll be able to close the Scripts dialog box and go back to using Eclipse.

Related Posts

See All

ESAPI Essentials 1.1 and 2.0

A few months ago, I introduced ESAPI Essentials—a toolkit for working with ESAPI (available via NuGet). I've recently added one major feature: asynchronous access to ESAPI for binary plugin scripts. Y

Announcement: ESAPI Subreddit

A few months ago, Matt Schmidt started the ESAPI subreddit. It's another useful resource for finding and discussing ESAPI-related topics. According to the description, This community is to post and di

Dump All Patient Data from ESAPI

If, for whatever reason, you need to dump out all of the data for a patient from ESAPI, there's a quick and dirty way to do it. Well, there are probably several ways to do it, but here's one I've foun


bottom of page