2011-09-30 19 views
8

Contesto
Quando il debug (con il menùDebug F5) una soluzione di Visual Studio, un processo chiamato MyApp.vshost.exe è stato creato. Quando si arresta il debug di indecentemente - voglio dire utilizzando il menu Debug arrestoSHIFT +F5 e non in attesa di una riga di codice come Application.Exit() si verifica - questo processo non viene ucciso.risolvere "il comando "taskkill/F/IM MyApp.vshost.exe" terminato con il codice 128" errore

A volte, quando in seguito si avvia nuovamente il debug dell'applicazione, viene visualizzato un messaggio di errore che indica che il file (ovviamente, è il file utilizzato dal debug: bin\Debug\MyApp.vshost.exe) è già in uso.

Questo è il motivo per cui ho aggiunto agli eventi costruire questa riga di comando: taskkill /F /IM MyApp.vshost.exe

Problema
Quando il processo MyApp.vshost.exe non esiste, Visual Studio è talvolta gettando un errore in fase di compilazione, evitando così di costruire l'applicazione:

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

L'unica soluzione esistente che ho trovato è rimuovere l'evento di build.

Domanda
C'è un modo per risolvere il messaggio di errore senza rimuovere l'evento di compilazione?

EDIT

sto pensando la soluzione migliore sarebbe quella di recuperare il codice di ritorno (errorlevel) del comando, per poi tornare 0 se è uguale a 128. E 'possibile farlo negli eventi Costruire del progetto?

+0

Puoi espandere ciò che stai facendo? Ad esempio, stai interagendo con app fuori processo come Excel o Word tramite i bit di Interop di Office? – Kev

+0

@Kev: ho il problema con tutte le mie applicazioni - _Windows form projects_ e _Windows services_ e alcune non funzionano con Excel né con Word. L'app più semplice che ho è un servizio che ha un timer che controlla in un database MSSQL ed esegue compiti semplici. – Otiel

+0

qualsiasi soluzione, problema analogo utilizzando msbuild: MSBUILD: avviso MSB3073: il comando "DEL" C: \ Clientes \ *. * "/ Q/f/s" è stato chiuso con il codice 128. – Kiquenet

risposta

15
taskkill /F /IM MyApp.vshost.exe 2>&1 || exit /B 0 
+6

Questo ha funzionato per me, tranne che ho avuto problemi fino a quando ho rimosso i doppi tubi, e ho reso un tubo singolo '||' a '|' –

+1

Ti suggerirei di usare test condizionali: 'taskkill/f/fi "pid gt 0"/im MyApp.vshost.exe' [Source] (http://stackoverflow.com/a/15748825/426315) – itsho

+0

Lo stesso qui. In VS 2015, il tubo singolo funziona taskkill/f/im excel.exe 2> & 1 | exit/B 0 –

2

Come misura temporanea è possibile disattivare il processo di Studio ospite a vista:

How to: Disable the Hosting Process

Per disattivare il processo di hosting

Aprire un progetto in Visual Studio.

Nel menu Progetto, fare clic su Proprietà.

Fare clic sulla scheda Debug.

Deselezionare la casella di controllo Abilita il processo di hosting di Visual Studio.

Gli effetti collaterali di fare questo può o non può essere desiderabile:

In generale, quando il processo di hosting è disabilitato:

Il tempo necessario per iniziare il debug di applicazioni .NET Framework aumenta.

La valutazione dell'espressione in fase di progettazione non è disponibile.

Il debug del trust parziale non è disponibile.

-1

in esecuzione forse come amministratore con privilegi completi l'IDE? (So ​​che questo è stato suggerito una volta da Microsoft)

+0

Nah, non esegue l'IDE come amministratore. – Otiel

2

Il MyApp.vshost.exe è il Visual Studio hosting process. Lo scopo di questo processo è migliorare l'esperienza di debug. Se uccidi questo processo, Visual Studio lo ricrea. Se si vuole sbarazzarsi di esso è possibile disattivare il processo di hosting nelle proprietà di debug per il progetto (C# mostrata qui):

Debug project properties

Lei descrive l'errore si verifica come "il processo è già in uso". Non penso di averlo sperimentato personalmente, ma su un PC di lavoro ho dei grossi problemi quando costruisco dopo il debug. Sembra che MyApp.exe sia bloccato e non possa essere sovrascritto ("il file è già in uso", non "processo") causando il fallimento della compilazione. Credendo che uno scanner antivirus (Microsoft Forefront) stia causando questi problemi, ma trovandosi in un ambiente aziendale non posso spegnere lo scanner per verificare la mia ipotesi.

In molti casi la disattivazione del processo di hosting non avrà un effetto notevole sulla tua esperienza di debug.

+0

Esatto, è _ "file già in uso" _ e non _ "processo" _. Ho modificato il mio Q. – Otiel

Problemi correlati