Ich habe eine Multi-Projekt-Lösung in Visual Studio 2008. Ich habe der Lösung gerade eine neue Konfiguration mit dem Namen Release-VersionIncrement hinzugefügt, in der die Konfiguration "Release verwenden" als Basis angegeben ist. Alle Projektdateien wurden mit dieser Konfiguration aktualisiert. Wenn ich jedoch versuche, ein bestimmtes Projekt mit dieser Konfiguration zu kompilieren, wird die folgende Fehlermeldung angezeigt:
Fehler 5 Die OutputPath-Eigenschaft ist für dieses Projekt nicht festgelegt. Stellen Sie sicher, dass Sie eine gültige Kombination aus Konfiguration und Plattform angegeben haben. Configuration = 'Release-VersionIncrement' Platform = 'AnyCPU' C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ Microsoft.Common.targets 539 9 DataConversion
Was passiert hier? Das Projekt lässt sich in der Release- oder Debug-Konfiguration problemlos kompilieren.
quelle
Antworten:
Normalerweise geschieht dies, wenn die OutputPath-Eigenschaft der Projektdatei leer ist. Projektdateien sind nur MSBuild- Dateien. So bearbeiten Sie in Visual Studio: Klicken Sie mit der rechten Maustaste auf das Projekt, wählen Sie "Projekt entladen", klicken Sie mit der rechten Maustaste auf das entladene Projekt und wählen Sie "Bearbeiten ...".
Suchen Sie nach der Eigenschaftsgruppe Release-Versionincrement. Es sollte ungefähr so aussehen
Der wichtige dort ist der OutputPath, existiert er für Ihre Projektdatei? Wenn nicht, fügen Sie es hinzu und versuchen Sie es erneut.
quelle
Ich habe diesen Fehler auch gesehen, als unser Build-Agent so konfiguriert wurde, dass die Plattform " Beliebige CPU " (mit Leerzeichen wie in Visual Studio angezeigt) anstelle von " AnyCPU " (ein Wort wie in der Projektdatei angegeben) ausgeführt wird.
quelle
msbuild myproj.sln /p:Configuration=Debug /p:Platform="Any CPU"
war in Ordnung, aber beimmsbuild myproj.proj1.csproj /p:Configuration=Debug /p:Platform=AnyCPU
Erstellen des Projekts musste ich den Speicherplatz in einer beliebigen CPU weglassen , um den Eigenschaftsfehler "Ausgabepfad" zu unterdrücken.Ich hatte das gleiche Problem, als ich MSBuild zuerst verwendete. Meine Lösung lautet: Verwenden Sie die OutputPath-Eigenschaft auf jeden Fall. So was:
quelle
In unserem Fall haben wir ein Build-Skript auf unseren HP Entwicklerboxen ausgeführt. HP hat einige Umgebungsvariablen, die sie für ihre eigenen Zwecke eingerichtet haben, und eine davon ist PLATFORM (wird anscheinend für "HP Easy Setup" verwendet).
Das Löschen der Umgebungsvariablen PLATFORM hat funktioniert.
Sie können Ihr Build-Skript auch zukunftssicher machen, indem Sie die Plattform angeben, d
msbuild /p:Platform=AnyCPU
. H.quelle
Wenn Visual Studio sich ausdrücklich über "Platform = 'BPC'" beschwert, können Sie dies leicht beheben, indem Sie die Umgebungsvariable "Platform" entfernen.
Starten Sie nun Visual Studio neu und Sie können loslegen.
quelle
Wie " Richard Dingwall " angedeutet hat, hängt das Problem mit VS zusammen, das die Anzeigeversion von " Any CPU " anstelle der MSBuild-Version verwendet, die tatsächlich " AnyCPU " lautet.
Gehen Sie zu Build / New Build Definition oder bearbeiten Sie Build Definition -> Prozess -> Zu erstellende Konfigurationen, öffnen Sie den Konfigurationsauswahldialog und wählen Sie unter " Plattform " die Option " Beliebige CPU" fügen Sie unter " " manuell " AnyCPU " hinzu.
quelle
Wie bereits erwähnt, muss OutputPath festgelegt UND zuvor
<Import Project="$(WixTargetsPath)" />
in die .wixproj-Datei eingefügt werdenquelle
Ich habe die
Platform
Umgebungsvariable entfernt (war BNB oder so etwas). Das Problem ist weg.quelle
Ich habe heute die x64-Plattform zu meiner Lösung hinzugefügt, als ich auf dieses Problem stieß.
In meinem Fall lautete der Fehler:
Ich wusste, dass das
OutputPath
in Ordnung sein sollte, da dies eine existierende, funktionierende VS-Lösung war. Also ging ich zum nächsten Hinweis über - "eine gültige Kombination aus Konfiguration und Plattform".Aha! Visual Studio versucht zu erstellen
Configuration='Debug', Platform='x64'
. Beim Betrachten meiner Projektdatei stellte ich fest, dass x64 nicht als eine der möglichen Plattformen aufgeführt war. Mit anderen Worten, ich hatte die folgenden Einträge (gekürzt):Einfache Lösung: Fügen Sie einfach x64-Einträge hinzu!
Ich habe die x86-Einträge kopiert / eingefügt und sie in x64 geändert. Beachten Sie, dass ich auch die Pfade geändert habe, damit diese x86-Builds nicht überschreiben:
quelle
Ich hatte eine Weile damit zu kämpfen und entlud, baute und lud dann das fehlerhafte Projekt in der Lösung neu, und dann funktionierte MSBuild korrekt.
quelle
Als Scott S musste ich die Umgebungsvariable "Platform" löschen .
Starten Sie dann VS neu und es ist in Ordnung: keine Fehlermeldung mehr ...
quelle
Das Problem hatte mit meiner Projektkonfiguration zu tun. Hier ist das Szenario:
Lösung A Referenzen:
Referenz zu Lösung B (die ich zu erstellen versuche):
Meine Lösung bestand darin, eine Konfiguration mit demselben Namen für Lösung A zu erstellen, sie neu zu erstellen und dann Lösung B neu zu erstellen. Dadurch wurde das Problem behoben.
quelle
Ich hatte die gleiche Fehlermeldung. Dies wurde durch einen Verweis auf ein Projekt verursacht, das entladen wurde und vom Linker nicht benötigt wurde (andernfalls wäre es beim Kompilieren fehlgeschlagen). Durch Entfernen der fehlerhaften Referenz wurde das Problem behoben.
quelle
In meinem Fall (VS2010) habe ich die Zeichenfolge im Feld "OutputPath" auf der Registerkarte "Build" entfernt und leer gelassen. Dann habe ich die Lösung neu aufgebaut. Die Erstellung war erfolgreich und VS hat das aktuelle Verzeichnis "./" in den "OutputPath" eingefügt. Ich habe das aktuelle Verzeichnis "./" durch meinen Pfad ersetzt ("bin \ x64 \ Release \" - es reicht zu sagen, dass dies der genaue Ordnerpfad ist, über den sich VS beschwert hat), und die Neuerstellung war erneut erfolgreich.
quelle
In meinem Fall wurde die Eigenschaft OutputPath in den Projektdateien festgelegt. Aber das Entladen, Nachladen und anschließende Wiederherstellen hat das Problem behoben.
quelle
Beim Hinzufügen einer neuen Lösungskonfiguration zu meiner Lösung wurde die Fehlermeldung "Die OutputPath-Eigenschaft ist für Projekt X nicht festgelegt. Stellen Sie sicher, dass Sie für dieses Projekt eine gültige Kombination aus Konfiguration und Plattform angegeben haben. Konfiguration = 'QA 'Platform =' AnyCPU '. Dieser Fehler kann auch auftreten, wenn ein anderes Projekt versucht, einem Projekt-zu-Projekt-Verweis auf dieses Projekt zu folgen. Dieses Projekt wurde entladen oder ist nicht in der Lösung enthalten, und das referenzierende Projekt nicht Erstellen Sie mit derselben oder einer gleichwertigen Konfiguration oder Plattform. ProjectY ".
In meinem Fall war das Problem auf einen hervorgehobenen Teil der Fehlerbeschreibung zurückzuführen. Projekt X Teil meiner Lösung war ein Projektverweis auf ProjectY einer anderen Lösung (anderer Zweig).
Ich habe dieses Problem behoben, indem ich Projekt X so geändert habe, dass in der aktuellen Lösung ein Projektverweis auf ProjectY verwendet wird. Hoffe das hilft jemandem mit ähnlichen Problemen.
quelle
In meinem Fall wurde der neue XML-Block "PropertyGroup" am Ende des Dokuments generiert. Ich habe es gerade nach anderen "PropertyGroup" -Tags ersetzt und dies hat das Problem behoben.
quelle
Ich habe ein neues Projekt in einer neuen Lösung erstellt, die auf vorhandene Projekte verweist. Dieser Fehler tritt auf, wenn ich ein vorhandenes Projekt hinzufüge (z. B. Projekt 1) und versuche, es zu erstellen, ohne andere Projekte hinzuzufügen, auf die Projekt 1 verweist.
Stellen Sie einfach sicher, dass alle zugehörigen Projekte zur neuen Lösung hinzugefügt wurden und der Fehler verschwindet.
quelle
Ich hatte den gleichen Fehler, also habe ich mir die Projekteinstellungen angesehen und dort im Abschnitt "Erstellen" die Option "Ausgabepfad erstellen". Und der Wert war leer. Also habe ich den Wert "bin \" eingegeben und ein Fehler ist verschwunden. Es hat mein Problem gelöst.
quelle
Wenn Sie OutputPath als Parameter festlegen und Ihr Pfad wie folgt lautet: Denken Sie
bin\Release\\
daran,\
am Ende Folgendes hinzuzufügen :/p:OutputPath=bin\Release\\\\
Es hat eine Weile gedauert, bis mir klar wurde, dass dies der Fall istquelle
Ich hatte das gleiche Problem. Ich habe es behoben, indem ich die Projekte sauber gemacht und neu aufgebaut habe.
quelle
Ich hatte das gleiche Problem und die einzige Lösung, die hilft, war das manuelle Festlegen der Build-Konfiguration in jedem NCrunch-Projekt.
Öffnen Sie das NCrunch-Fenster, in dem Sie den Status jedes Builds sehen und sehen können, dass der Build fehlschlägt. Klicken Sie mit der rechten Maustaste auf das Projekt, das nicht erstellt werden kann, und klicken Sie auf "Ausgewählte Komponente konfigurieren". Dort sehen Sie unter "Build-Einstellungen" die Eigenschaft "Build-Konfiguration verwenden", z. B. "Debuggen" und die Eigenschaft "Build-Plattform verwenden" zB "AnyCPU". (Bitte beachten Sie, dass die von Ihnen festgelegten Build- und Konfigurationseinstellungen in Ihren Konfigrationseinstellungen vorhanden sein müssen.)
Tun Sie dies für alle Ihre Projekte, aber nicht für Ihr Testprojekt. Danach funktioniert alles gut für mich.
quelle
Ich hatte das gleiche Problem. Ich habe es behoben, indem ich dem fehlgeschlagenen Projekt fehlende Konfigurationen hinzugefügt habe.
Klicken Sie unter Konfigurationsspalte hinzufügen auf
Hinweis: Dies lag nur daran, dass ich eine benutzerdefinierte Konfiguration habe und neu erstellte Projekte diese Konfiguration nicht hatten.
quelle
Wenn jemand dieses in seinen NCrunch-Protokollen erhält, überprüfen Sie, ob sich die
PropertyGroup
Definition der Werte 'Debug' / 'Release' und 'AnyCPU' / 'x86' vor den Eigenschaftsgruppen befindet, die diese Werte in ihrem Zustand verwenden.Hat für mich gearbeitet.
quelle
In meinem Fall habe ich versucht, die Eigenschaftsgruppe, die meine benutzerdefinierte Konfiguration enthielt, unter die Standardkonfiguration zu verschieben. Es hat es für mich gelöst.
quelle
Hatte gerade das mit VS2015 Professional:
Dies ist auch ein Multiprojekt-Jonglieren zwischen Debug / Release und verschiedenen Zielen. Ich hatte irgendwann mit Build-Konfigurationen herumgespielt und weiß, dass dies VS durcheinander bringen kann, also habe ich sie aus dem Repo zurückgezogen. Immer noch nicht gut. OutputPath wurde festgelegt, es gab keine Unterschiede mehr mit einem bekanntermaßen guten Zustand, sodass definitiv etwas mit meiner lokalen Installation nicht stimmte.
Öffnete das VS2015-Installationsprogramm und klickte auf "Reparieren" und voila ... wieder normal (zumindest bisher!)
quelle