Eine ähnliche Frage wurde vor ungefähr einem Jahr gestellt und beantwortet, war jedoch entweder ein anderes Problem (alles war in der Beta) oder wurde falsch diagnostiziert. Es befindet sich hier:MSbuild-Task schlägt fehl, weil die "Any CPU" -Lösung nicht in der richtigen Reihenfolge erstellt wurde.

Mein Problem ist, dass ich ein Wix-Installationsprojekt habe. Nach dem Upgrade auf Tfs2010 am Montag schlägt der Build beim Verknüpfen fehl, da das Build-Produkt der Wpf-Anwendung im Projekt nicht gefunden wird. Nach einigem Graben ist es, weil es noch nicht gebaut wurde. Das Einrichten von Vs2010 funktioniert wie gewohnt. Das wix-Projekt ist so eingestellt, dass es vom Wpf-Projekt abhängt. Wenn Sie die Projekterstellungsreihenfolge in der IDE anzeigen, sieht alles wie gewohnt aus.

Das Problem wurde ursprünglich nur mit zwei Plattformdefinitionen in der Lösung festgestellt. x86 und x64. Es gibt auch zwei Varianten, Debug und Release, und TFSBuild.proj ist so eingestellt, dass alle vier Kombinationen erstellt werden. AnyCPU trat nirgends auf. In der oben genannten Frage habe ich versucht, das Wpf-Projekt so zu ändern, dass AnyCPU verwendet wird, sodass es zuerst erstellt wird. Zu diesem Zeitpunkt verwendete das Wix-Projekt die genaue Konfiguration und das Wpf-Projekt die Version mit AnyCPU. Dies schien jedoch nichts zu ändern.

Ich verwende Tfs2010 RTM, Vs2010 RTM und die aktuellste Version von Wix, die zum Zeitpunkt dieses Schreibens 3.5.1602.0 vom 02.04.2010 ist. Läuft sonst noch jemand darauf?

27.04.2010: Nach einigem Graben und Reproduzieren auf einer geklonten VM-Build-Maschine, glaube ich zu wissen, was los ist und was fehlschlägt, aber ich weiß nicht genau, wie ich das beheben soll.

Die Situation ist, dass dieser Fehler Symptome zu zeigen scheint, die auf der reinen Glücksspiel-Projektbestellung in der Lösungsdatei beruhen. Es sieht so aus, als würde die Lösungsdatei die Projekte nur blind in der Reihenfolge erstellen, in der sie angezeigt werden, und sich dabei auf die Fähigkeit verlassen, nicht erstellte Referenzen zu erkennen und sie bei Bedarf zu erstellen.

In meiner speziellen Lösungsdatei wurde mein Wix-Projekt vor meinem Wpf-Anwendungsprojekt bestellt. Dies führte dazu, dass das Wix-Projekt zuerst erstellt wurde und während die Abhängigkeit vom Wpf-Projekt korrekt erkannt wurde, wurde die eigentliche MSBuild-Aufgabe aufgrund der undefinierten Variablen $ (BuildProjectReferences) übersprungen. Ich erwähne hier einige Kommentare aus dem Hauptbeitrag Faden. Wenn MSBuild-Ausführlichkeit noch diagnostiziert ist, kann BuildProjectReferences als undefiniert angesehen werden, wenn das Wix-Projekt erstellt wird, und es kann als wahr angesehen werden, wenn das Wpf-Projekt innerhalb der Aufgabe zum Erstellen des Wix-Projekts erstellt wird. Beim Testen wird undefined jedoch erneut ausgewertet, die Aufgabe wird übersprungen und der Wix-Build schlägt fehl, da die Build-Ausgabe des nicht erstellten Wpf-Projekts nicht gefunden werden kann.

So Fazit: Die Projektabhängigkeit wird aufgrund einer fehlerhaften $ -Variable (BuildProjectReferences) übersprungen. Interessanterweise ist diese Variable nur in der Datei Wix2010.targets und nicht in wix.targets vorhanden. Ich denke, das ist der Grund, warum dies nur angezeigt wird, nachdem ich Tfs2010 und Vs2010 installiert habe.

Die Lösung: Wie stelle ich sicher, dass BuildProjectReferences korrekt an die nachfolgenden MSBuild-Aufgaben weitergegeben wird? Gibt es etwas Besonderes mit variablem Scoping?

14.09.2010: Für dieses Problem wurde im WiX-Toolset ein Fehler festgestellt:http: //sourceforge.net/tracker/? func = detail & atid = 642714 & aid = 2990231 & group_id = 105970 und vor einiger Zeit behoben. Hoffentlich ist dies kein Problem mehr. Wenn ja, öffnen Sie bitte einen neuen Bug.

Um Ihren Kommentar direkt zu adressieren, enthält nichts in meiner Lösung eine AnyCPU-Konfiguration in den Build-Dateien. Ich habe die AnyCPU-Konfigurationen nur erstellt, um die von dem Thread vorgeschlagene Lösung zu testen, auf den ich in meinem ursprünglichen Beitrag verlinkt habe. Nachdem es nicht geklappt hat, habe ich die AnyCPU-Konfigurationen wieder entfernt.

Außerdem befinden sich die Projekte in derselben Lösungsdatei, jedoch in separaten Lösungsordnern (Schnittstellenordner, Installationsordner), falls dies von Bedeutung ist.

Interessanterweise wollte ich ein kleines Sandbox-Beispiel erstellen, um das Problem zu veranschaulichen, das ich hatte. Nachdem ich jedoch meine winzige Musterlösung erstellt hatte, konnte ich den Fehler nicht reproduzieren. Dies lässt mich vermuten, dass dies möglicherweise auf die Verwendung eines Teamprojekts zurückzuführen ist, das von einem Tfs2008-Teamprojekt aufgerüstet wurde, anstatt eines Projekts, das in Tfs2010 neu erstellt wurde. Ich kann versuchen, mein Projekt in ein neues zu verzweigen, um diese Theorie zu testen, wenn ich nicht herausfinden kann, warum die Testlösung funktioniert.

p.s. Außerdem ist Stackoverflow für mich neu - warum in aller Welt sind Kommentare in der Länge begrenzt, wenn der Workflow "Beantworte deine eigene Frage" nur konkrete Antworten liefern soll?

So warf ich die Build-Ausführlichkeit auf Diagnose und las sie heute durch, und eine Zeile fiel mir besonders auf:

Task "MSBuild" skipped, due to false condition; ('@(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').

Dies wurde gesehen, als mein Installationsprojekt versuchte, mein wpf-Projekt zu erstellen, da auf das wpf-Projekt verwiesen wird. Insbesondere wird $ (BuildProjectReferences) aus irgendeinem Grund als "" ausgewertet, wenn ich mir ziemlich sicher bin, dass es "wahr" sein sollte.

Jedoch zu Beginn der MSBuild-Aufgabe für das WpfApp-Projekt im Protokoll sah ich Folgendes:

Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true

So war die Eigenschaft zwar bis zum Beginn der Aufgabe korrekt, wurde dann aber scheinbar überschrieben? Mir ist irgendwie unklar, wie diese Eigenschaften eingestellt werden.