11

Context
When debugging (with the Debug menu F5) a Visual Studio solution, a process called MyApp.vshost.exe is created. When you stop the debug indecently - I mean using the Stop Debug menu SHIFT+F5 and not waiting for a code line like Application.Exit() occurs - this process is not killed.

Sometimes, when you later start again debugging your application, an error message occurs, saying that the file (obviously, it is the file used by the debug: bin\Debug\MyApp.vshost.exe) is already in use.

That is why I added to the Build events this command line: taskkill /F /IM MyApp.vshost.exe

Problem
When the MyApp.vshost.exeprocess does not exist, Visual Studio is sometimes throwing an error at build time, thus preventing to build the application:

Error c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
The command "taskkill /F /IM MyApp.vshost.exe" exited with code 128.

The only existing solution i found is to remove the build event.

Question
Is there a way to resolve the error message without removing the build event?

EDIT

I'm thinking the best solution would be to retrieve the return code (errorlevel) of the command, then return 0 if it is equal to 128. Is it possible to do it in the Build events of the project?

Community
  • 1
  • 1
Otiel
  • 18,404
  • 16
  • 78
  • 126
  • Can you expand on what you're application is doing? For example, are you interfacing with out of process apps such as Excel or Word via the Office Interop bits? – Kev Oct 01 '11 at 22:11
  • @Kev: I have the problem with all my applications - _Windows form projects_ and _Windows services_ and some are not working with Excel nor Word. The simplest app I have is a service that got a timer checking in a MSSQL database and execute simple tasks. – Otiel Oct 01 '11 at 22:46
  • any solution, similar problem using msbuild: MSBUILD : warning MSB3073: The command "DEL "C:\Clientes\*.*" /q /f /s" exited with code 128. – Kiquenet Oct 06 '11 at 11:29

4 Answers4

18
taskkill /F /IM MyApp.vshost.exe 2>&1 || exit /B 0
Otiel
  • 18,404
  • 16
  • 78
  • 126
  • 7
    This worked for me, except I had problems until I removed the double pipes, and made it a single pipe `||` to `|` – Justin Pihony May 02 '12 at 17:24
  • 1
    I would suggest to use conditional testing: `taskkill /f /fi "pid gt 0" /im MyApp.vshost.exe` [Source](http://stackoverflow.com/a/15748825/426315) – itsho Mar 08 '15 at 08:23
  • Same here. In VS 2015, single pipe works taskkill /f /im excel.exe 2>&1 | exit /B 0 – Steve Johnson Jun 25 '16 at 10:12
  • In theory it should be double pipe: "The double pipe (||) causes the command following this symbol to run if the command preceding the symbol fails". From http://windowsitpro.com/windows/jsi-tip-0290-conditional-processing-symbols-filters-and-redirection-batch-processing – kristianp Sep 08 '16 at 22:55
2

As a temporary measure you can disable the Visual Studio host process:

How to: Disable the Hosting Process

To disable the hosting process

Open a project in Visual Studio.

On the Project menu, click Properties.

Click the Debug tab.

Clear the Enable the Visual Studio hosting process check box.

The side effects of doing this may or may not be desirable:

In general, when the hosting process is disabled:

The time needed to begin debugging .NET Framework applications increases.

Design-time expression evaluation is unavailable.

Partial trust debugging is unavailable.

Kev
  • 118,037
  • 53
  • 300
  • 385
2

The MyApp.vshost.exe is the Visual Studio hosting process. The purpose of this process is to improve the debugging experience. If you kill this process yourself Visual Studio will recreate it. If you want to get rid of it you can turn off the hosting process in the debugging properties for the project (C# shown here):

Debug project properties

You describe the error you experience as "the process is already in use". I don't think I have experienced that myself but on a work PC I'm having great troubles when building after debugging. It seems that MyApp.exe is locked and cannot be overwritten ("file is already in use", not "process") causing the build to fail. By belief is that a virus scanner (Microsoft Forefront) are causing these problems, but being in a corporate environment I can't turn off the scanner to test my hypothesis.

In many cases disabling the hosting process will not have a noticable effect on your debugging experience.

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
-1

running perhaps as administrator with full privileges the IDE ? ( I know this was suggested once upon a time from Microsoft )

hephestos
  • 434
  • 1
  • 6
  • 19