MsBuild nicht in das gute Verzeichnis für Abhängigkeiten der zweiten Ebene der benutzerdefinierten Aufgabe

Ich schrieb eine MsBuild Task: MyTask. In meiner Lösung habe ich das Task-Projekt und andere Projekte. MyTask verweist auf ein Projekt (z. B. ProjA), das auf dritte Assemblys verweist (z. B. dep1 und dep2).MsBuild nicht in das gute Verzeichnis für Abhängigkeiten der zweiten Ebene der benutzerdefinierten Aufgabe

Die Projekte alle baut gut und ich habe die Ausgänge in einem Verzeichnis (Compil). In diesem Verzeichnis habe ich alle DLLs, die ich möchte: MyTask.dll, ProjA.dll, dep1.dll, dep2.dll und andere.

In meiner MsBuild Datei enthalten i die benutzerdefinierte Aufgabe Montage mit:

<UsingTask AssemblyFile="..\Compil\MyTask.dll" TaskName="CreateSitesCss" />

Dann rufe ich eine Aufgabe der MyTask Montage. Der Anruf wird gut ausgeführt, aber MsBuild beschwert sich über nicht die dep1 und DEP2 Baugruppen zu finden (obwohl sie im selben Verzeichnis) sind:

Fehler: Konnte nicht ‚Datei oder Assembly dep1 laden, Version = 2.0.0.0, Culture = neutral, PublicKey Token = 9109c11469ae1bc7 'oder eine seiner Abhängigkeiten. Die angegebene Datei wurde vom System nicht gefunden.

Ich kann dieses Problem lösen, indem dep1.dll Kopieren und dep2.dll auf c: \ windows \ Microsoft .NET \ Framework \ v4.0 \ aber ich will nicht, dies zu tun, weil es Probleme auslöst, wenn Erstellen anderer Projekte (kopiert nicht die Dateien dep1.dll und dep2.dll in das Ausgabeverzeichnis ...).

Hat jemand das gleiche Problem, oder besser, eine Lösung?

EDIT

Hier ist der Ausgang der Fusion Log Viewer

*** Assembly Binder Log Entry (19/10/2010 @ 17:52:45) *** 

The operation failed. 
Bind result: hr = 0x80070002. The system cannot find the file specified. 

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\clr.dll 
Running under executable c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe 
--- A detailed error log follows. 

=== Pre-bind state information === 
LOG: User = HEADOFFICE\bbaumann 
LOG: DisplayName = ProjA 
(Partial) 
WRN: Partial binding information was supplied for an assembly: 
WRN: Assembly Name: ProjA | Domain ID: 1 
WRN: A partial bind occurs when only part of the assembly display name is provided. 
WRN: This might result in the binder loading an incorrect assembly. 
WRN: It is recommended to provide a fully specified textual identity for the assembly, 
WRN: that consists of the simple name, version, culture, and public key token. 
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. 
LOG: Appbase = file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = MSBuild.exe 
Calling assembly : System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. 
=== 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.Config 
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). 
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA.DLL, because the location falls outside of the appbase. 
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA/ProjA.DLL, because the location falls outside of the appbase. 
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA.EXE, because the location falls outside of the appbase. 
WRN: Not probing location file:///d:/svn/twilight/_build/ProjA/ProjA.EXE, because the location falls outside of the appbase. 
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA.DLL. 
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA/ProjA.DLL. 
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA.EXE. 
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/ProjA/ProjA.EXE. 
LOG: All probing URLs attempted and failed.

Und wenn ich MSBuild.exe in das Verzeichnis kopieren, in dem alle meine dll sind, funktioniert es gut ..
MsBuild scheint nicht nach dep1.dll und dep2.dll in meinem Compil-Verzeichnis zu suchen, auch wenn es ProjA.dll in ...

findet

EDIT

Was, wie meine Bindungen fertig sind: MyTask verweist auf das proja Projekt von:

<ProjectReference Include="..\ProjA\ProjA.csproj"> 
    <Project>{ED61DCC3-D759-4D44-B802-A6A46F328402}</Project> 
    <Name>ProjA</Name> 
</ProjectReference>

proja verweist auf die zwei Abhängigkeiten von

<Reference Include="dep1, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\Dependencies\dep1\dep1.dll</HintPath> 
</Reference> 
<Reference Include="dep2, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\Dependencies\dep2\dep2.dll</HintPath> 
</Reference>

Quelle

2010-09-09 Benjamin Baumann

möglich Duplikat [Verwenden Sie benutzerdefinierte MSBuild Aufgaben aus der gleichen Lösung?] (Http://stackoverflow.com/questions/282615/use-custom-msbuild-tasks-from-the-same-solution) –

Nein. Ich habe das Thema gesehen, das du verlinkt hast. In diesem Fall kann msbuild die Taskassembly nicht laden, da der Pfad nicht gut ist. In meinem Fall ist die Aufgabe gut geladen, die erste Abhängigkeit (ProjA) auch, aber die Abhängigkeiten der zweiten Ebene (dep1 und dep2) nicht. –

Haben Sie jemals eine * richtige * Lösung für dieses Problem gefunden? Ich denke, ich habe jetzt das gleiche Problem. – theDmi

Das könnte dir Probieren Sie den Fusion Log Viewer (fuslogvw.exe, installiert mit VisualStudio) aus, um zu sehen, welche Pfade gesucht werden ched für die Baugruppen. Möglicherweise finden Sie einen anderen Ordner, der stattdessen verwendet werden kann.

Wenn dep1 und dep2 Baugruppen von Drittanbietern oder interne sind, die sich nicht ändern, könnten Sie sie immer in den GAC werfen. Dies ist etwas, das ich auf einem Build-Server normalerweise vermeide, aber wenn Sie sie nur für Build-Helfer und nicht für Produktionsinstallationen verwenden, sollte das kein Problem sein.

Edit: Die partial bind könnte die Ursache sein. Verwenden Sie Assembly.Load, um ProjA zu verwenden?Von den Logs, die Sie zur Verfügung gestellt haben, sieht es so aus, als würde es ProjA nicht laden - es wird nicht weit genug, um sogar dep1 oder dep2 zu laden.

Quelle

2010-10-01 21:08:00 Pedro

Ich werde versuchen, Fusion Log Viewer dies wird ein konkreteres Ergebnis als die Kommentare von microsoft.csharp.targets geben. Was die GAC betrifft, sind dep1 und dep2 Projekte, die wir machen, also ändern sich die dlls. Deshalb ziehe ich es vor, sie manuell zu msbuilddir zu kopieren und sie danach zu löschen ... –

Danke für Ihre Hilfe. Ich habe meinen Post mit meinen verbindlichen Konfigurationen bearbeitet. Ich lade Baugruppen nicht nach Code, sondern nur nach Konfiguration. Ich denke, das Protokoll scheint, dass es PROJA (in der Tat die Abhängigkeiten dep1 und dep2) VOLLSTÄNDIG lädt, die mit MSBUild Fehlermeldung übereinstimmt: "Datei oder Assembly konnte nicht geladen werden dep1, Version = 2.0.0.0, Culture = neutral, PublicKey Token = 9109c11469ae1bc7 '" –

Ich gebe dir die Belohnung Pedro, weil du mir am meisten geholfen hast, aber ich habe immer noch nicht meine Antwort:' (Danke, Pedro. –

Es gibt ein paar Arbeitsumgebungen, die ich suggest.

ILMerge dies ermöglicht es Ihnen zusammen mehrere Baugruppen verschmelzen, in einer Baugruppe.
Sie können die sekundäre Referenz zu Ihrer Lösung hinzufügen, auch wenn Sie sie nicht verwenden, dies würde sie in Ihren bin-Ordner kopieren.
erstellen Sie ein anderes Ziel nach der Kompilierung ausführen, um die fehlenden Assembly in den Ordner

hoffte, das hilft zu kopieren.

Iain

Quelle

2010-10-20 10:32:04 Iain

Ich kenne ILMerge und es könnte das Problem lösen. Aber ich werde es nur in der letzten Option verwenden (ich mag vielleicht sogar MSBuild.exe in das Verzeichnis kopieren). Wie für Optionen 2 und 3: Die Dateien sind im Ausgabeordner, sie sind privat (copylocal in VS) und alles ist in Ordnung. Ich habe dies mehrmals mit C# DLL-Projekte ohne Schaden. Aber mit einem MSBuild Custom Task, MSBuild scheint nicht nach den Assemblies der zweiten Ebene im Curren zu suchen t Verzeichnis ... –

Haben Sie jemals Fortschritte gemacht? Ich habe das gleiche Problem fast 7 Jahre später! (https://stackoverflow.com/questions/44976387/how-do-i-make-msbuild-find-net-assemblies-when-using-a-custom-task-usingtask). Ich werde ILMerge auch versuchen. Ich benutze VS2015 und Msbuild 14.0. –

MsBuild nicht in das gute Verzeichnis für Abhängigkeiten der zweiten Ebene der benutzerdefinierten Aufgabe

Antwort

Verwandte Themen