Visual Studio 2008 sperrt DLL in bin-Ordner und lässt es nicht los

Ich arbeite an einer Lösung bestehend aus 8 .NET-Projekten. Da ich TDD praktiziere, muss ich meine Lösung sehr oft neu kompilieren. In letzter Zeit habe ich über jedes zweites Mal die folgende Fehlermeldung erhalten, wenn zu kompilieren versuchen:Visual Studio 2008 sperrt DLL in bin-Ordner und lässt es nicht los

Fehler 2 können nicht kopiert werden Datei „obj \ Debug \ Zeiterfassung.Tests.dll“ zu „ist \ Debug \ Zeiterfassung. Tests.dll ". Der Prozess kann nicht auf die Datei 'bin \ Debug \ Zeiterfassung.Tests.dll' zugreifen, da sie von einem anderen Prozess verwendet wird.

Zeiterfassung.Tests.dll ist die DLL, die von einem meiner Projekte generiert wird (es ist das Unit-Test-Projekt). Es ist immer diese DLL, die nicht kopiert werden kann und den Fehler verursacht. Alles andere funktioniert in 100% der Fälle.

In etwa 9/10 Mal kann ich das Problem "lösen", indem ich meine Lösung neu kompiliere. Aber wenn das Problem wirklich schlecht wird, wird das Projekt einfach nicht erfolgreich kompiliert, egal wie oft ich es versuche und ich muss die IDE neu starten.

Ich habe microsoft's handle.exe verwendet, um festzustellen, welcher Prozess die DLL schließt und es devenv.exe ist. Ich habe auch versucht, die DLL von Hand zu löschen und es kann wirklich nicht gelöscht werden, bis ich die IDE neu starte.

Last but not least habe ich versucht, <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> zu meinem Projekt hinzuzufügen, wie in einem anderen Forum vorgeschlagen, aber das hat nicht geholfen.

Bitte helfen! Dieses Problem beginnt mich wirklich verrückt zu machen.

Bearbeiten: Ich könnte auch hinzufügen, dass ich sicher, dass meine Komponententests beendet sind, wenn dieses Problem auftritt. Trotzdem bleibt die DLL gesperrt. Ich führe meine Tests mit dem Resharper Unit Test Explorer durch.

Quelle

2009-07-21 Adrian Grigore

Sieht aus wie der Bug verschwunden (die Daumen ...) Nachdem ich mein Testprojekt verschoben habe, habe ich eine frühere Version des Projekts aus dem Repository ausgecheckt und alle Codedateien durch die neueren Versionen ersetzt.

Quelle

2009-07-22 12:14:12

Wenn das funktionierte, macht es mir Sorgen. Das bedeutet, dass Sie irgendwo in Ihrem Code ein Problem haben, das Sie versehentlich hinzugefügt und jetzt entfernt haben. Es könnte später zu Instabilität führen. – Randolpho

Es scheint eher so, als hätte ich innerhalb der letzten Tage ein Problem eingeführt, das zu diesem Problem geführt hat, und jetzt habe ich das Problem mit meinem Code behoben, indem ich auf die vorherige Codeversion zurückkehrte. –

Vielleicht müssen Sie nur neu starten, verwenden Sie Windows lol. –

Ich habe das gleiche Problem zuvor konfrontiert. Process Explorer kann das Handle löschen.

Quelle

2009-07-21 21:38:16

Sie haben Recht! Aber wie kann ich das automatisieren? Das Problem tritt so oft auf, dass das Schließen des Handles in ProcessExplorer viel zu viel Aufwand verursacht. –

Zwei Dinge. Der Process Explorer sollte angegeben haben, in welchem Prozess die Datei geöffnet wurde. War es ein Debug-Lauf des Prozesses mit einem losen Thread? Visual Studio selbst? Zweitens ist das einzige Mal, dass mein Team ein Problem mit der "DLL-Sperrung" hat, wenn wir einen Zirkelverweis im Projekt haben. Projekt A erfordert B erfordert C, die A. Visual Studio selbst ist in der Regel das mit der DLL gesperrt. –

Visual Studio selbst hat die DLL gesperrt. Aber ich konnte keinen Zirkel finden. –

Das wahrscheinlichste Problem ist ein Threading-Problem. Sie hatten wahrscheinlich einen Wanderfaden, der immer noch ausgeführt wird, und er hat den Verweis auf .DLL.

Quelle

2009-07-21 21:39:41 Randolpho

Danke für den Hinweis, aber wie kann ich das Problem beheben? –

Adrian, benutzt Ihr Projekt Mulit-Reading-Fähigkeiten? Das Problem liegt wahrscheinlich im Code Ihrer Anwendung. –

@Adrian: Wie Spencer vorschlägt, wenn Sie Threads verwenden, wäre der Fix in Ihrem Code. Es gibt zu viele Möglichkeiten, um an dieser Stelle eine Lösung vorzuschlagen. – Randolpho

Visual Studio hatte seit Tag 1 das eine oder andere Problem. Es wäre schön, Ihnen eine Reihe einfacher Lösungen zu geben, die immer funktionieren, aber ehrlich gesagt, manchmal hat es einfach "über seine eigenen Füße gestolpert".

In diesem Fall ist die einfache Lösung zu beenden und neu zu starten. Selbst das Schließen der Lösung und das erneute Öffnen können nicht helfen.

Quelle

2009-07-21 21:52:07

Ja, das habe ich bisher gemacht. Aber alle 10 Minuten die IDE neu starten zu müssen, hat gravierende Auswirkungen auf meine Produktivität. –

Mit „Ich habe versucht, das Hinzufügen wahr zu meinem Projekt als in einem anderen Forum vorgeschlagen“ meinen Sie, dass Sie eine Eigenschaft mit dem Namen erstellt GenerateResourceNeverLockTypeAssemblies und setzen Sie ihn auf wahr wie bei http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032 vorgeschlagen? Wenn nicht, versuchen Sie es.

Sayed Ibrahim Hashimi

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

Quelle

2009-07-22 02:02:11

Hoppla, vergessen Sie, das GenerateResourceNeverLockTypeAssemblies-Tag als Code zu markieren und es wurde daher in meinem Beitrag nicht angezeigt. Ja, das habe ich schon versucht. –

Dies funktionierte für mich: 1) Erstellen Sie einen neuen Ordner außerhalb des Projekts (c: \ Debug); 2) Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie Eigenschaften; 3) Suchen Sie die Registerkarte Erstellen; 4) Navigieren Sie auf der Registerkarte Erstellen zum Abschnitt Ausgabe (der letzte in VS2010); 5) Klicken Sie auf Durchsuchen und wählen Sie Ihren neuen c: \ Debug-Speicherort als Ausgabeverzeichnis; 6) Speichern Sie alle Änderungen; 7) Build (F6);

Quelle

2010-11-10 00:56:48

Ich hatte eine similar problem. Ich kenne keine nette Lösung, aber ein Hack, der das Problem löst, ist ein Pre-Build-Ereignis hinzuzufügen, das vstest.executionengine.exe tötet:

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

Quelle

2013-05-24 10:41:15 Wilbert

Visual Studio 2008 sperrt DLL in bin-Ordner und lässt es nicht los

Antwort

Verwandte Themen