Click here to Skip to main content
15,895,606 members
Articles / Programming Languages / C++
Article

Kill Running Project Process Add-In

Rate me:
Please Sign up or sign in to vote.
3.67/5 (2 votes)
24 Jun 20042 min read 55.2K   995   14   9
Killing a running project process within Visual Studio

Image 1

Introduction

How many times have you been in the situation, during development, you had to kill the current project process for any reason (infinite loops, crazy threads, a wrong return value and so on) ? It happens continuously, I guess.

What to do then? I always have the Task Manager minimized to the System Tray and when I need to kill the project process I click it up, scrolling the tasks list, found mine end kill it. Too much time wasted! ... :)

So it came to my mind to simplify the killing procedure, making it as fastest as possible: Why not having a button in the IDE to do the job for us? An Add-In would help. So here it is.

Image 2

Background

To understand the source code, it is just needed to read any other Add-in article in this CodeProject section.

The code

The DevStudio Add-Ins Wizard does the main job for us to crate an Add-In, in fact the code you have to implement is simply the one relative to what the Add-In you're creating stands for: in this case killing the active project running process.

The method to implement is ICommand::KillProcessCommandMethod()

STDMETHODIMP CCommands::KillProcessCommandMethod() 
{
  
  AFX_MANAGE_STATE(AfxGetStaticModuleState());

  // Let's simplify the conversion work between OLE 
  // strings and C strings ...
  USES_CONVERSION;
  
  CComPtr<IDispatch> iDisp=NULL;
  
  // Obtain the IDispatch pointer
  m_pApplication->get_ActiveProject(&iDisp);
  
  // Obtain the IGenericProject interface through the IDispatch interface
  CComQIPtr<IGenericProject, &__uuidof(IGenericProject)> pProject(iDisp);
  
  // Is there any active project? If there's none, get out gracefully
  if(pProject == NULL)
    return S_OK;
  
  // Prepare the project name string
  CComBSTR bstrName=NULL;
  
  // Obtain the name of the project
  pProject->get_Name(&bstrName);
  
  // We suppose that the name of the executable is the same 
  // as the project one, with an appended '.exe' extension.
  bstrName+=".exe";
  
  
  // We need to make some logic on the executable name now...
  
  // Convert an OLE string to a C constant string pointer 
  LPCTSTR stringa = OLE2T(bstrName);
  
  // Let's make our string editable
  LPSTR str = (LPSTR)stringa;
  
  // We need to know how long is the name of the 
  // executable because in the running process list
  // only 15 characters are reported, every character 
  // over the 15th is truncated:
  // i.e. 'MyApplication.exe'  is reported as 'MyApplication.e' and so on.
  
  int len = strlen(str);
  
  // Let's make some logic and if the length of the name is over 15, 
  // let's put NULLs on the extra characters.
  // This is needed because once we obtain the running process list, 
  // we will iterate on it and find the process to kill on a 
  // strcmp name basis.
  
  if(len > 15)
  {
    for(int i = 15; i < len; i++)
      if(*(str + i)!=NULL)
        *(str + i) = NULL;
  }
  
  
  // Let's take a snapshot of the running process list
  
  HANDLE hSnapShot=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
  
  // Prepare the struct to contains every process information
  
  PROCESSENTRY32* processInfo=new PROCESSENTRY32;
  processInfo->dwSize=sizeof(PROCESSENTRY32);

  DWORD processID = 0;
  BOOL bFound = FALSE;
  
  // Iterate through processes to find ours...
  
  while(Process32Next(hSnapShot,processInfo)!=FALSE)
  {
    // store the Process ID
    processID = processInfo->th32ProcessID;
    
    // Is this our running process to kill?
    if(strcmp(processInfo->szExeFile,str) == 0)
    {
      bFound = TRUE;
      break;
    }
  }

  CloseHandle(hSnapShot);
  
  if(bFound)
  {
    // Obtain the Process handle....
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS,TRUE,processID);
    
    // and Kill it
    if(hProcess != NULL)
      TerminateProcess(hProcess,0);

  }

  return S_OK;
}

Hints

Remember to include in StdAfx.h the following header files:

#include <comdef.h>
#include <winbase.h>
#include <tlhelp32.h>

Copy the KillProcess.dll in the <Visual Studio Install Dir>\Common\MSDev98\Addins folder

Limitations

As stated in the code comments, we forced the name of the executable to be the same as the project one, plus an '.exe' extension.
this is not very portable. I tried to find through the

IConfiguration
interface or IBuildProject interface to obtain the name of the executable to be produced but maybe I followed the wrong way. If you have any hint or comment are always welcome. Thanks. Fabio

History

  • 24 June 2004 v1.0

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Software Developer (Senior)
Italy Italy
Worked as a Java developer targeting J2EE and J2SE for half a decade.

Now he's employed for Avanade as a Senior Associate Consultant on Microsoft technologies.

His hobbies are Win32 programming using SDK, MFC, ATL and COM; playing guitar and listening to music.

Comments and Discussions

 
Generalover-termination Pin
frogola1-Sep-05 6:13
frogola1-Sep-05 6:13 
GeneralRe: over-termination Pin
Fabio Fornaro5-Sep-05 22:09
Fabio Fornaro5-Sep-05 22:09 
Questionif the exe file is not a same name as the project's? Pin
renguangyu2-Aug-04 23:31
renguangyu2-Aug-04 23:31 
AnswerRe: if the exe file is not a same name as the project's? Pin
Fabio Fornaro3-Aug-04 21:25
Fabio Fornaro3-Aug-04 21:25 
GeneralRe: if the exe file is not a same name as the project's? Pin
renguangyu3-Aug-04 22:31
renguangyu3-Aug-04 22:31 
GeneralRe: if the exe file is not a same name as the project's? Pin
Fabio Fornaro3-Aug-04 22:39
Fabio Fornaro3-Aug-04 22:39 
Yeah, you're right 'dsp' file has all the configuration stuff needed by the project, but we need an abstraction layer supplied by the IDE automation to cut the dependency by a particular file format implementation. That's what interfaces stand for.

So I don't think it's a good idea to let the addin depending on the '.dsp' file format (even if I don't think it's going to change) because it's not a good programming pattern.

Best thing would be to find out how the IDE automation interfaces handles the project executable name, so if the file format changes we'll stay behind the interfaces not minding about what changed in the low level layer.

regards,
Fabio

GeneralRe: if the exe file is not a same name as the project's? Pin
renguangyu3-Aug-04 23:48
renguangyu3-Aug-04 23:48 
Question?????????????? Pin
NGS 54967225-Jun-04 4:51
NGS 54967225-Jun-04 4:51 
AnswerRe: ?????????????? Pin
Fabio Fornaro25-Jun-04 5:57
Fabio Fornaro25-Jun-04 5:57 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.