Nicht laden referenzierten Bibliothek

Ich bekomme diese Fehlermeldung in Visual Studio 2008 bei der Entwicklung einer ASP.NET Web-Anwendung-Projekt.

Nicht laden referenzierten Bibliothek
'Path-to-DotNetNuke\bin\file.dll': Die
Prozess kann nicht auf die Datei zugreifen, da
es wird von einem anderen Prozess verwendet.

Dies ist ein Portal-Projekt mit mehreren Modulen. IIS lädt alle Baugruppen aus dem /bin-Ordner unter dem root der Anwendung.

Die Projekte in der Projektmappe sind in Ihren jeweiligen /DesktopModules/Projektname-Ordner und kompilieren, um eine bin-Ordner unter dem Projekt.

Tritt der Fehler auf, nachdem ich die Projektmappe kompilieren und kopieren Sie alle Projekte' dlls in den /bin mit einem Skript. Visual Studio läßt mich nicht neu kompilieren, aber wenn ich es neu starten, funktioniert alles ok. Das ist wirklich ärgerlich, wenn Sie kompilieren und testen Sie die gesamte Lösung. Müssen Sie Visual Studio neu starten, zwischen jeder neu kompilieren.

Konnte ich nicht finden, eine beliebige Datei-locks mit dem Process Explorer bei Visual Studio zeigt diesen Fehler.

[UPDATE] Es ist eine alte MSDN-Dokument, die sagt, dass Sie nicht bauen werden alle DLLs in einen Ordner wenn Sie auf über 64 KB-DLL gibt. Particulartly, das Dokument sagt:

Es bewirkt, dass der build-Prozess zu scheitern
mit lock-Datei, wenn ein Fehler
referenzierte assembly überschreitet 64 KB
Größe.

Wir haben die Verweise auf über 64 KB-DLLs im /bin-Ordner und kopieren neu kompilierten DLLs, die es auszulösen scheint, zumindest mit VB-IDE-hintergrund-compiler.

  • Hast u finden, eine Lösung? Ich habe das gleiche Problem. Es passiert mir einmal, ich kopiere die kompilierte assembly aus einer Lösung auf den Ordner "Verweis" von einer anderen Lösung und versuchen zu kompilieren. Mit vs2008.
InformationsquelleAutor mika | 2009-02-07
  1. 2

    Tritt der Fehler auf, nachdem ich die Projektmappe kompilieren und kopieren Sie alle Projekte' dlls in den /bin mit einem Skript. Visual Studio läßt mich nicht neu kompilieren, aber wenn ich es neu starten, funktioniert alles ok.

    Ich würde vorschlagen, Einstellung der Ausgabe-Verzeichnis jedes Ihrer Projekte zu werden, das bin Verzeichnis der DotNetNuke-website. Dies wird Ihnen helfen zu vermeiden, die manuelle Schritt des Kopierens von Dateien insgesamt.

    Zum einstellen der Ausgabe-Verzeichnis des Projekts: klicken Sie Rechts auf Ihr Projekt im Projektmappen-Explorer und wählen Sie Eigenschaften. Wählen Sie die Registerkarte erstellen, wählen Sie Alle Konfigurationen (oben) und Ausgabe-Pfad auf "..\..\bin" (fast ganz unten). Dieser nimmt Ihr Projekt-Datei in der typischen Stelle in das Modul-Verzeichnis (z.B. DesktopModules/YourModule/YourProject.csproj) ansonsten können Sie navigieren Sie zu Ihrer Website in das bin-Verzeichnis mit der nebenstehenden Schaltfläche "durchsuchen".

    • Wissen Sie, ob diese noch aktuell ist? weblogs.asp.net/bsimser/archive/2005/05/25/408850.aspx msdn.microsoft.com/en-us/library/ms998223.aspx ich denke, es erklärt das problem.
    • Einrichten DNN-Module auf diese Weise ist nicht nur gemein, es ist etwas von einer 'best practice'. Ich habe nicht erlebt, die Probleme, die Sie sprechen, in den letzten drei Jahren der Entwicklung von DNN-Module.
    • Ich glaube, diese Artikel gelten nur bis zu VS .NET 2003, und ich, zusammen mit @irobinson, haben niemals gesehen, dass diejenigen, die Symptome in VS2005 oder VS2008.
    • Ich erlebe dies in VS2010, wenn Gebäude ein offenes Projekt mit einem Skript. VS neu gestartet werden muss, bevor es erneut kompilieren.
    InformationsquelleAutor Ian Robinson
Schreibe einen Kommentar