wake-up-neo.com

Referenz DLL Datei wird nicht in Bin mit Bereitstellungsprojekt kopiert, was Fehler verursacht

Wir haben mehrere externe DLL - Dateien, auf die in unserem Webanwendungsprojekt verwiesen wird. Wir haben ein Bereitstellungsprojekt für die Installation auf den Hosting-Servern. Bei der Verwendung von .NET 3.5 und Visual Studio 2008 wurde die Datei DLL in den Ordner bin kopiert. Da wir ein Upgrade auf .NET 4 und Visual Studio 2010 durchgeführt haben, geschieht dies nicht mehr und es werden Serverfehler angezeigt, da die Referenzen nicht gefunden werden können.

CopyLocal ist auf true gesetzt, und ich kann nichts in der web.config finden, was darauf hindeutet, dass dies an anderer Stelle festgelegt wird.

57
g.foley

In Visual Studio 2010 gibt es einen Fehler. Standardmäßig sieht das XML in der Lösungsdatei folgendermaßen aus:

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
</Reference>

MSBuild erwartet dies unten, sodass die Datei DLL in die Bereitstellung aufgenommen wird:

<Reference Include="DevExpress.SpellChecker.v11.1.Core,
           Version=11.1.5.0,
           Culture=neutral,
           PublicKeyToken=b88d1754d700e49a,
           processorArchitecture=MSIL">
<HintPath>..\References\DevExpress.SpellChecker.v11.1.Core.dll</HintPath>
<Private>True</Private>
</Reference>

Der Trick ist, Copy Local auf False zu setzen, das Projekt zu speichern und dann auf True - erneut zu speichern zurückzusetzen. Dies schließt den privaten Knoten korrekt ein, den MSBuild berücksichtigt.

Es scheint, dass der Standardwert für keinen enthaltenen privaten Knoten (Copy Local) in Visual Studio 2010 True ist, während MSBuild diesen fehlenden Knoten als False liest.

101
Rebecca

Ich bekam das gleiche Problem und anstatt einen Schritt "BeforeBuild" hinzuzufügen, erstellte ich einen Test, der dies einfach tat

    [TestMethod]
    public void ReferenceAssemblyThatDoesNotCopyToBuildFolder()
    {
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler referenceThisButDoNotUseIt = null;
    }

Und damit der Fehler behoben Der Typ 'Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler ...' kann nicht aufgelöst werden

3
stevie_c

Bei meinem Bereitstellungsprojekt ist etwas Merkwürdiges passiert. Als ich sah, dass es keine erkannten Abhängigkeiten gab, entfernte ich die primäre Ausgabe und fügte sie erneut hinzu. 

Die Abhängigkeiten werden jetzt angezeigt und bei der Installation im Ordner bin abgelegt.

2
g.foley

Ich bekam genau das gleiche Problem. Wir haben ein Visual Studio 2008-Projekt, das auf die EnterpriseLibrary verweist. Wenn wir unseren integrierten Build mit TFS und unserem Webbereitstellungsprojekt ausführen, werden alle DLL -Dateien kopiert. Bei einem Upgrade auf Visual Studio 2010, TFS 2010 und WDP 2010 fehlten einige der Dateien DLL. Seltsamerweise tritt dies nur bei einigen DLL -Dateien auf und nicht bei anderen.

Beispielsweise erhalten wir die Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll in beiden Fällen kopiert, nicht jedoch die Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll.

Als Problemumgehung habe ich die Dateien mit einem "BeforeBuild" -Schritt kopiert.

Es scheint jetzt OK zu bauen.

1
Patrick Magee

Ich hatte gerade das gleiche Problem und wollte mitteilen, was ich gefunden habe, da es jemandem helfen könnte:

Der Grund in meinem Fall war, dass die Assembly während einer Installation einer Drittanbieteranwendung im GAC installiert wurde.

Wenn sich die Datei DLL im GAC befindet, muss der Compiler sie nicht in den Zielordner kopieren, sofern Sie sie nicht speziell für "Kopie lokal" kennzeichnen, indem Sie den Knoten "Private" in der Projektdatei verwenden, wie von Junto.

Die Sache ist, wenn Sie diesen Knoten nicht hinzufügen und auf einem Computer entwickeln und auf einem anderen aufbauen, und die Datei DLL nur im GAC des Build-Computers vorhanden ist, ist das Standardverhalten ohne private node bewirkt, dass die Datei auf der Entwicklungsmaschine korrekt kopiert wird, jedoch nicht auf der Buildmaschine.

Das größere Problem ist, wenn auf die Datei DLL nicht direkt verwiesen wird, das Projekt jedoch auf ein zweites Projekt verweist, das wiederum auf die Datei DLL verweist. In diesem Fall können Sie die DLL -Datei im Projekt nicht als "lokal kopieren" markieren, da sie nicht darauf verweist. Wenn die Datei DLL im GAC vorhanden ist, wird sie nicht in Ihren Ausgabeordner kopiert.

Mögliche Lösungen für diesen Fall sind:

  • Deinstallieren Sie die Datei DLL vom GAC
  • Fügen Sie einen direkten Verweis auf die Datei DLL in den Endprojekten hinzu.
  • Signieren Sie die Datei DLL erneut mit einem neuen starken Namen, der sie von der Datei DLL im GAC unterscheidet.
1
rzen

Ich hatte ein ähnliches Problem mit VS 2012 Express. Ich habe in meinem Projekt Tesseract-Bibliotheken verwendet. Alles hat gut funktioniert, bis ich dieses Projekt in einer Lösung verwendet habe, bei der es mehr als ein Projekt gab. Das Problem war, dass einige DLLs (liblept168.dll, libtesseract302.dll), die normalerweise in den Ordnern bin/debug/x86 oder bin/debug/x64 abgelegt werden, nur kopiert wurden, wenn ich die gesamte Lösung rekonstruierte wieder verursacht, dass die DLLs gelöscht und nicht zurück kopiert wurden.

Ich habe dieses Problem gelöst, indem ich dem Startprojekt einen Verweis auf das Projekt hinzugefügt habe, das fehlende DLLs erstellt.

0
chviLadislav

Wenn Ihr Projekt die Bibliothek nicht direkt lädt, wird es nicht immer bereitgestellt, selbst wenn explizit darauf verwiesen wird! Ich wurde verwirrt, weil ich es in einem lokalen Bin-Verzeichnis sehen konnte, aber nicht bei der Bereitstellung. Die DLL im Bin-Verzeichnis war eine alte Datei, die während der Bereinigung nicht entfernt wurde, weshalb ich verwirrt war.

Eine vollständige Neukonstruktion und Neuerstellung, und es war auch nicht in meinem lokalen Bin-Ordner, der mir das Problem zeigte (ich verwende es nur in web.config). Ich habe dann auf die DLL-Datei selbst im Projekt verwiesen und sie so eingestellt, dass sie in die Ausgabe kopiert wird, um sicherzustellen, dass sie bereitgestellt wird.

0
Lukos

rzen und andere, danke - Ihre Kommentare führten zu einer Lösung für uns.

Wir haben ein Projekt, das auf Version 10 der Assemblys Microsoft.ReportViewer.Common.dll und Microsoft.ReportViewer.WebForms.dll abzielt (separater Ordner "libs", den wir auf der 'src'-Ebene erstellt haben). Als wir jedoch einen Build erstellten, enthielt die Ausgabe Version 12, die kürzlich auf dem Build-Server installiert wurde.

Durch Kommentare hier haben wir sichergestellt, dass 'Copy Local' auf "True" gesetzt wurde und das Flag in der Projektdatei gesetzt wurde. Es wurde jedoch immer noch Version 12 bereitgestellt. Der Trick bestand also darin, sicherzustellen, dass die Eigenschaft 'Specific Version' auch für die beiden Referenzen festgelegt wurde. Voila, Version 10 jeder Datei wird jetzt bereitgestellt!

Es gab viel Freude.

JH

0
John H

Wir können den <Private>False</Private> verwenden, um die referenzierten DLL -Dateien nicht in das Verzeichnis bin zu kopieren. Dies ist nützlich, wenn wir Anwendungen auf einem separaten TFS-Build-Server erstellen, auf dem die Anwendung erstellt werden muss und die Dateien DLL nicht in das Verzeichnis bin kopiert werden sollen. 

0
jrapolu

Ich bin nicht sicher, wie es in Visual Studio 2008 eingerichtet wurde, aber ich bin fast sicher, dass Sie die Befehlszeile des Post-Build-Ereignisses verwendet haben. Dort können Sie die DLL -Dateien kopieren, die Sie für die Bereitstellung benötigen. Ein Beispiel ist unten angegeben: 

mkdir $(SolutionDir)\Deployment
copy "$(SolutionDir)Your_Library_Name\Your_Dll_ForDeployement.dll" 
$(SolutionDir)\Deployment\
0
VoodooChild

Auch ich stieß auf ein ähnliches Problem, bei dem referenzierte DLLs nicht in die Bin im veröffentlichten Ordner kopiert wurden. Ich habe eine TFS-ausgecheckte Kopie verwendet, die den Ordner bin nicht in die Anwendung aufgenommen hat. -> Also einfach den bin-Ordner enthalten. -> Erstellte die referenzierten Anwendungen -> Das Website-Projekt wurde veröffentlicht Jetzt sehe ich alle referenzierten dlls in bin im veröffentlichten Ordner

0
user4869201

Ich habe nicht das gleiche Problem getroffen, aber ähnlich. Ich hatte ein WPF-Hauptprojekt und ein referenziertes Projekt, bei dem das referenzierte nicht kopiert wurde. Ich habe festgestellt, dass in meinem Fall das Hauptprojekt für das NET 4.0-Clientprofil und das für NET 3.5 referenzierte Projekt festgelegt war. Wenn ich das Hauptprojekt auf 3.5 eingestellt habe, wurde die kompilierte DLL des referenzierten Projekts mit dem Kopieren begonnen.

0
Bronek

Überprüfen Sie das Framework des Projekts, in dem die Datei DLL referenziert wurde. Das Framework sollte .NET 4.0 sein. Bitte korrigieren Sie es, wenn das Rahmenprofil "Client Profile" ist.

0