Visual Studio 2015 blocca DLL durante il debug

Question

Ho 3 progetti C# A, B e C. Entrambi A e B riferimento C. I riferimenti a C da A e B sono impostati su "Copia locale", il che implica che dopo la creazione di C a C.dll (nella directory di output di C), viene copiato nella directory di output di A o B (qualunque sia in fase di compilazione)

Ho 2 soluzioni, SA e SB. SA contiene A e C e SB contiene B e C. Lancio 2 istanze di Visual Studio 2015. Apro SA in una istanza e SB nell'altra.

Sto trovando che se avvio Debugging (F5) A da SA, e quindi (mentre A è ancora in fase di debug), apporta una modifica a C da SB e tenta di compilare SB, viene visualizzato un errore di compilazione che indica che C .dll non può essere sovrascritto perché è in uso da un altro processo (l'istanza di devenv.exe che esegue SA).

Questo non ha senso per me perché dopo aver compilato da C a C.dll e copiato nella directory di output di A, Visual Studio dovrebbe rilasciare il blocco sul file.

Ho verificato (tramite la finestra di moduli in SA) che la versione di C.dll caricata è quello che è stato copiato nella directory di output di A.

Questo è iniziato che si verificano ieri, quando ho iniziato a usare visivo Studio 2015 (anziché Visual Studio 2013).

Qualcuno ha qualche idea? La mia soluzione attuale è eseguire SA via CTRL-F5 (avvia senza debug), ma questo diventa fastidioso quando voglio eseguire SA e SB in modalità di debug simultaneamente.

Grazie.

UPDATE

ho fatto qualche ricerca in cui la "Modifica e continuazione" caratteristica potrebbe causare il comportamento descritto, e in base a questa pagina https://msdn.microsoft.com/en-us/library/ms164926.aspx> Modifica e continuazione uno permette di effettuare modifiche al codice sorgente, mentre in un sessione di debug e i risultati diventano effettivi senza interrompere il debug, la ricompilazione e il riavvio della sessione di debug (quale problema fondamentale deve essere stato). Con questa funzionalità abilitata, a Visual Studio potrebbe essere richiesto di ricompilare qualsiasi DLL dipendente in qualsiasi momento, il che spiega il blocco.

Answer 1

Ho avuto lo stesso problema. Ho cambiato le mie impostazioni VS2015 e sembra che il problema è scomparso:

• Opzioni disabili \ debug \ Modifica e continuazione
• -Opzioni \ Sourcecodemanagement da TFS a NONE-
• -disabled Opzioni \ debug \ Strumenti diagnostici durante il debug-

Non sono sicuro che uno abbia causato il blocco, ma ho il sospetto che gli strumenti di diagnostica che non avevo in VS2013. (Le impostazioni nomi che tradotto dal tedesco all'inglese, non so se è esattamente come vengono chiamati in inglese VS versione.)

Edit: Come ricercato da Shea è stato l'Edit-E- Continuare la funzione che ha bloccato la DLL.

Answer 2

Ho avuto lo stesso problema e nessuna delle altre soluzioni consigliate che ho trovato durante la ricerca nell'interwebs ha funzionato per me.Finalmente dopo aver "riparato" Visual Studio 2015 Enterprise, ho provato a lanciare Visual Studio in modalità provvisoria: devenv.exe/SafeMode

In modalità provvisoria sono riuscito finalmente a costruire la mia soluzione, e quando ho ripreso senza l'interruttore, ho era pronto a chiudere le estensioni una alla volta finché non ho trovato quale fosse il colpevole. Fortunatamente non era necessario e le build successive sono andate avanti senza intoppi.

Answer 3

nel mio caso questo è stato "Panda Free Antivirus" che stava guardando sul dll del progetto "C", e questo ha causato l'errore: "il processo non può accedere al file perché è utilizzato da un altro processo"

Answer 4

Nel mio caso, il file .pdb era bloccato. Questo non è lo stesso di .exe bloccato come dovrebbe essere durante il debug.

Supponendo che sia solo lo .pdb, è sufficiente spostarlo in una nuova cartella (che ho trascinato e lasciato cadere). Stranamente, non può essere cancellato, ma può essere sicuramente spostato! Una volta eliminato il file .pdb, l'assembly è stato in grado di ricompilare nuovamente.

La soluzione alternativa (e probabilmente la meno conveniente) comporta la chiusura completa del progetto, quindi l'apertura di nuovo (il file .pdb si sblocca magicamente!).

Modifica: Dopo aver eseguito una seconda volta, lo spostamento del file non ha funzionato; sembra che il riavvio del progetto è l'unico modo affidabile per andare.