7 Stimmen

Visual Studio 2008 sperrt die DLL im Bin-Ordner und lässt sie nicht mehr los

Ich arbeite an einer Lösung, die aus 8 .NET-Projekten besteht. Da ich TDD praktiziere, muss ich meine Lösung sehr oft neu kompilieren. In letzter Zeit habe ich den folgenden Fehler etwa jedes zweite Mal, wenn ich versuche zu kompilieren:

Fehler 2 Datei kann nicht kopiert werden "obj \Debug\Zeiterfassung.Tests.dll " auf "bin \Debug\Zeiterfassung.Tests.dll ". Der Prozess kann nicht auf die Datei 'bin \Debug\Zeiterfassung.Tests.dll ' weil sie von einer anderen Person verwendet wird Prozess verwendet wird.

Zeiterfassung.Tests.dll ist die dll, die von einem meiner Projekte erzeugt wird (es ist das Unit-Testing-Projekt). Es ist immer diese dll, die nicht kopiert werden kann und den Fehler verursacht. Alles andere funktioniert 100 % der Zeit gut.

In etwa 9/10 Fällen kann ich das Problem durch erneutes Kompilieren meiner Lösung "lösen". Aber wenn das Problem wirklich schlimm wird, lässt sich das Projekt einfach nicht erfolgreich kompilieren, egal wie oft ich es versuche, und ich muss die IDE neu starten.

Ich habe Microsofts handle.exe verwendet, um festzustellen, welcher Prozess die DLL sperrt, und es ist devenv.exe. Ich habe auch versucht, die DLL von Hand zu löschen, aber sie kann wirklich erst gelöscht werden, wenn ich die IDE neu starte.

Zu guter Letzt habe ich versucht, Folgendes hinzuzufügen <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies> zu meinem Projekt hinzugefügt, wie in einem anderen Forum vorgeschlagen, aber das hat nicht geholfen.

Bitte um Hilfe! Dieses Problem fängt wirklich an, mich verrückt zu machen.

Editar: Ich könnte auch hinzufügen, dass ich sichergestellt habe, dass meine Unit-Tests abgeschlossen sind, wenn dieses Problem auftritt. Dennoch bleibt die DLL gesperrt. Ich führe meine Tests über den Resharper-Unit-Test-Explorer.

4voto

Mark P Neyer Punkte 1011

Ich stand schon einmal vor demselben Problem. Prozess-Explorer in der Lage ist, den Griff zu löschen.

1voto

Randolpho Punkte 54011

Das wahrscheinlichste Problem ist ein Einfädelungsproblem. Sie hatten wahrscheinlich einen itineranten Thread, der noch ausgeführt wird und den Verweis auf die DLL hat.

1voto

Alex O. Punkte 11

Das hat bei mir funktioniert: 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 Build; 4) Navigieren Sie auf der Registerkarte "Build" zum Abschnitt "Output" (letzter Abschnitt in VS2010); 5) Klicken Sie auf die Schaltfläche Durchsuchen und wählen Sie Ihr neues c: \Debug Speicherort als Ausgabeverzeichnis; 6) Speichern Sie alle Änderungen; 7) Erstellen (F6);

0voto

John Saunders Punkte 159011

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

In diesem Fall besteht die einfache Lösung darin, das Programm zu beenden und neu zu starten. Auch das Schließen der Lösung und erneutes Öffnen kann nicht helfen.

0voto

Von " Ich habe versucht, true zu meinem Projekt hinzuzufügen, wie in einem anderen Forum vorgeschlagen "Meinen Sie damit, dass Sie eine Eigenschaft namens GenerateResourceNeverLockTypeAssemblies und setzen es auf wahr wie vorgeschlagen unter http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6f76db9a-ea37-42b3-a016-571912c28032 ? Wenn nicht, probieren Sie das aus.

Sayed Ibrahim Hashimi

Mein Buch: Einblick in die Microsoft Build Engine: Verwendung von MSBuild und Team Foundation Build

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X