Visual Studio 2008 blocca la DLL nella cartella bin e non la lascia andare

Sto lavorando a una soluzione composta da 8 progetti .NET. Dal momento che sto praticando TDD, devo ricomporre la mia soluzione molto spesso. Ultimamente ho ottenendo il seguente errore circa ogni seconda volta quando si cerca di compilare:Visual Studio 2008 blocca la DLL nella cartella bin e non la lascia andare

errore 2 Impossibile copiare il file "obj \ Debug \ Zeiterfassung.Tests.dll" per "bin \ Debug \ Zeiterfassung. Tests.dll". Il processo non può accedere al file "bin \ Debug \ Zeiterfassung.Tests.dll" perché è utilizzato da un altro processo .

Zeiterfassung.Tests.dll è la DLL generata da uno dei miei progetti (è il progetto di test dell'unità). È sempre questa DLL che non può essere copiata e causa l'errore. Tutto il resto funziona bene il 100% delle volte.

In circa 9/10 volte posso "risolvere" il problema ricompilando nuovamente la mia soluzione. Ma quando il problema si sta mettendo davvero male, il progetto non verrà compilato correttamente, non importa quanto spesso provo e devo riavviare l'IDE.

Ho usato microsoft's handle.exe per verificare quale processo sta bloccando la DLL ed è devenv.exe. Ho anche provato a cancellare la DLL a mano e in realtà non può essere cancellata fino a quando non riavvio l'IDE.

Ultimo ma non meno importante, ho provato ad aggiungere <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> al mio progetto come suggerito in un altro forum, ma questo non ha aiutato.

Si prega di aiuto! Questo problema sta davvero iniziando a farmi impazzire.

Modifica: Potrei anche aggiungere che mi sono assicurato che i miei test di unità siano terminati quando si verifica questo problema. Tuttavia, la dll rimane bloccata. Sto eseguendo i miei test tramite l'unit test explorer di Resharper.

fonte

2009-07-21 Adrian Grigore

Sembra che il bug è scomparso (incrociamo le dita ...) dopo che ho spostato il mio progetto di test, ho controllato una versione precedente del progetto dal repository e ho sostituito tutti i file di codice con le versioni più recenti.

fonte

2009-07-22 12:14:12

Se questo ha funzionato, mi preoccupa. Significa che hai un problema nel codice da qualche parte che hai aggiunto per sbaglio e che ora hai rimosso. Potrebbe portare all'instabilità in seguito. – Randolpho

Mi sembra piuttosto come se avessi introdotto un problema che ha portato a questo problema negli ultimi giorni e ora ho rimosso il problema con il mio codice tornando alla versione precedente del codice. –

Forse hai solo bisogno di riavviare, stai usando Windows lol. –

Ho già affrontato lo stesso problema. Process Explorer è in grado di eliminare l'handle.

fonte

2009-07-21 21:38:16

Hai ragione! Ma come posso automatizzare questo? Il problema si verifica così spesso che chiudere l'handle in ProcessExplorer è troppo oneroso. –

Due cose. Process Explorer avrebbe dovuto indicare quale processo aveva aperto il file. Era un debug-run del processo con un thread libero? Visual Studio stesso? In secondo luogo, l'unica volta che il mio team ha un problema con la "DLL locking" è quando abbiamo un riferimento circolare nel progetto. Il progetto A richiede B richiede C che richiede A. Visual Studio stesso è solitamente quello con la DLL bloccata. –

Visual Studio stesso ha la DLL bloccata. Ma non sono riuscito a trovare alcun riferimento circolare. –

Il problema più probabile è un problema di threading. Probabilmente hai avuto un thread itinerante che è ancora in esecuzione e ha il riferimento a .DLL.

fonte

2009-07-21 21:39:41 Randolpho

Grazie per il suggerimento, ma come posso risolvere il problema? –

Adrian, il tuo progetto usa un qualche tipo di funzionalità per il multithreading? Il problema è probabilmente nel codice dell'applicazione da qualche parte. –

@Adrian: come suggerisce Spencer, se stai usando thread la correzione sarebbe nel tuo codice. Ci sono troppe possibilità per suggerire una correzione a questo punto. – Randolpho

Visual Studio ha avuto uno o l'altro problema del genere dal primo giorno. Sarebbe bello darvi una serie di soluzioni semplici che funzionano sempre, ma francamente, a volte, è semplicemente "inciampato nei suoi stessi piedi".

In questo caso, la soluzione semplice è uscire e riavviare. Anche la chiusura della soluzione e la riapertura potrebbero non essere d'aiuto.

fonte

2009-07-21 21:52:07

Sì, questo è quello che ho fatto finora. Ma dover riavviare l'IDE ogni 10 minuti incide seriamente sulla mia produttività. –

Con "Ho provato ad aggiungere fedele al mio progetto come suggerito in un altro forum" Vuoi dire che è stata creata una proprietà denominata GenerateResourceNeverLockTypeAssemblies e impostarla su vero come suggerito a http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032? Se non lo provi.

Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

fonte

2009-07-22 02:02:11

Oops, ho dimenticato di contrassegnare il tag GenerateResourceNeverLockTypeAssemblies come codice e quindi non è stato mostrato come tale nel mio post. Sì, è quello che ho già provato. –

Questo ha funzionato per me: 1) Crea una nuova cartella all'esterno del Progetto (c: \ Debug); 2) Fare clic con il pulsante destro del mouse sul progetto e selezionare Proprietà; 3) Trova la scheda Crea; 4) Passare alla sezione Output nella scheda Build (l'ultima in VS2010); 5) Fare clic sul pulsante Sfoglia e selezionare la nuova posizione c: \ Debug come directory di output; 6) Salva tutte le modifiche; 7) Build (F6);

fonte

2010-11-10 00:56:48

Ho avuto un similar problem. Non conosco una soluzione piacevole, ma un hack che risolve il problema è aggiungere un evento pre-build che uccide vstest.executionengine.exe:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1" 
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

fonte

2013-05-24 10:41:15 Wilbert

Visual Studio 2008 blocca la DLL nella cartella bin e non la lascia andare

risposta

Problemi correlati