<kill processName="peskyLittleProcess" />

posted @ Monday, June 11, 2007 11:38 PM

 

For a second time now, I've found myself needing to kill processes in my automated build scripts, so that was enough for me to automate it and wrap it up in a custom NAnt task.  The first time I needed it, I just embedded the C# code inside a NAnt script block, but using it as "real" NAnt task is much nicer.  And, perhaps I overlooked it, but I did not see a task in the set of NAnt or NAntContrib tasks to do this kind of simple operation and Google didn't turn up anything either.  So I just banged it out real quick...

Here's how it can be used:

   1: <loadtasks assembly="pathToToolsFolder\joeyDotNet.Commons.dll" />
   2: <kill processName="w3wp" />

 

And for those that are interested, here's the code for the task, although it's really quite simple: 

   1: /// <summary>
   2: /// Looks for processes with specified name and kills them
   3: /// </summary>
   4: [TaskName("kill")]
   5: public class KillTask : Task
   6: {
   7:     private string processName;
   8:  
   9:     [TaskAttribute("processName", Required = true), StringValidator(AllowEmpty = false)]
  10:     public string ProcessName
  11:     {
  12:         get { return processName; }
  13:         set { processName = value; }
  14:     }
  15:  
  16:     protected override void ExecuteTask()
  17:     {
  18:         Log(Level.Info, "Looking for processes named {0}...", processName);
  19:         foreach (Process process in Process.GetProcessesByName(processName))
  20:         {
  21:             Log(Level.Info, "Found process named {0}, killing...", processName);
  22:             process.Kill();
  23:         }
  24:     }
  25: }

 

Disclaimer:  I take no responsibility for what happens if try to pass in a process name like "System" or "winlogon" or "explorer".   So please use wisely...  :)

As usual, you can grab the source code yourself from the repository.

Comments
joeyDotNet - 6/12/2007 8:56 AM
# re: <kill processName="peskyLittleProcess" />
Well, I've never had to kill anything directly related to my CI environments. More related to deployment and run targets. Here are a couple instances in particular (pretty unique to the situation):

1) On a couple of the smart client projects I worked on over the past year, as part of the build script, I included targets to allow the entire application (winforms client and WCF console-based service host) to be compiled and started directly from the build script, eliminating the need to open VS if you just wanted to run the latest bits locally. Well, when you'd close down the winforms client, the console service host would stay open since it was in another process. So as part of the "run" target, after the <exec /> task that started the winforms client, I included a simple step which would kill the console service host process after the winforms client was closed, so that the client and service tiers would both start and close as a single unit, even though they were 2 separate processes.

2) Another thing I run into sometimes is the asp.net worker process placing locks on some folder. For instance, I like to use the aspnet_compiler.exe directly to compile, deploy and run my web applications. Well, this usually consists of the build script creating some new folders, compiling the web app and creating a new IIS vdir to point to the newly created folders. So all this is fine the first time this is run. The problem arises when you try to run it a 2nd time, in which my "clean" target deletes all the old deployment folders as part of the build preparation. But the asp.net worker process (aspnet_wp, w3wp) still has a lock on those folders, so the delete operation fails. In this case I added a kill task as part of my "clean" target to kill any worker processes that may be locking those folders. Works like a champ...

Anyways, that was a bit long-winded, but you asked for specific examples... :)
Tiago Vieira - 2/11/2008 6:15 PM
# re: <kill processName="peskyLittleProcess" />
Thanks Joe!

What a great snap I did now to solve my problem.

Sometimes the some systems were interfering on my Automated Build process. Calling a Kill.exe that I've created using exec wasn't a good coding practice.

Now I can insert just a simple (and readable) line of code.

Cheers!

Tiago Vieira
Post Comment






Please add 5 and 3 and type the answer here: