Die OutputPath-Eigenschaft ist für dieses Projekt nicht festgelegt

120

Wenn ich versuche, mein Projekt aus dem x86-Debug-Modus in Visual Studio 2008 zu kompilieren, wird dieser Fehler angezeigt. Wenn ich mir die Eigenschaftsgruppe des beanstandeten Projekts anschaue, sehe ich, dass der Ausgabepfad festgelegt ist.

Hier ist der Eigenschaftsgruppenabschnitt für diese .csproj-Datei

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <DebugSymbols>true</DebugSymbols>
  <OutputPath>bin\x86\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <BaseAddress>285212672</BaseAddress>
  <FileAlignment>4096</FileAlignment>
  <DebugType>full</DebugType>
  <PlatformTarget>x86</PlatformTarget>
 <ErrorReport>prompt</ErrorReport>

Kann jemand das Licht ins Dunkel bringen?

HINWEIS: Als ich dieses Debug und jede CPU kompiliert habe, hat es funktioniert.

AKTUALISIERT: Fehler 1 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. Konfiguration = 'Debug' Plattform = 'x86'

Amzath
quelle
Ok und welche Konfiguration und Plattform verwenden Sie? Debug + x86 oder was anderes?
Ondrej Tucny
Ja VS Konfigurationsmanager Ich wähle Debug + x86
Amzath
@DmitryShkuropatsky aktualisierte Fehlermeldung
Amzath
1
Es sieht richtig aus. Gibt es ein anderes Projekt in der Lösung, das den Fehler verursachen kann?
Dmitry Shkuropatsky
@DmitryShkuropatsky Sie haben Recht, es war ein anderes Projekt, das Probleme hatte. Aber VS beschwerte sich über das Projekt, das kompiliert wird
Amzath

Antworten:

214

Ich hatte genau den gleichen Fehler, nachdem ich eine neue Konfiguration über ConfigurationManager in Visual Studio hinzugefügt hatte.

Als die 'Production'-Konfiguration für die gesamte Lösung (und jedes Projekt) hinzugefügt wurde, wurde das OutputPath-Element nicht zu den .csproj-Dateien hinzugefügt.

Um dies zu beheben, habe ich in den Projekteigenschaften die Registerkarte "Erstellen" aufgerufen, "OutputPath" von \bin\Production\in \bin\Production( nachfolgend gelöscht \) geändert und die Änderungen gespeichert. Diese erzwungene Erstellung des OutputPath-Elements in der .csproj-Datei und des Projekts wurde erfolgreich erstellt.

Klingt für mich nach einer Panne.

Roman Gudkov
quelle
7
Netter Fang bei diesem Quecksilberfehler. Hätte nie gedacht, dass ein einziger Schrägstrich einen so großen Unterschied machen könnte. Haben Sie ein gutes Antwortabzeichen.
Ouflak
8
In meinem Fall beim Erstellen einer Projektdatei war der Unterschied zwischen any cpuund anycpudas Problem, aber Ihr Beitrag hat mir dabei geholfen, das zu erkennen.
Joshua Drake
2
Danke Roman, du hast meinen Tag gerettet ... wenn ich deine Antwort nur 100 Mal positiv bewerten könnte! :)
Martin
2
Gerade in VS 2017 v15.6.6 angetroffen, Speck gespeichert, danke!
Angrist
1
@ Joshua Drake, dies ist ein wichtiges Problem bei der Verwendung von VSTS. Visual Studio Online verwendet "jede CPU", während lokales Visual Studio "anycpy" verwendet. Wichtig für Build-Skripte.
FrankyHollywood
27

Sie können diesen Fehler in VS 2008 sehen, wenn Ihre Lösung ein Projekt enthält, das auf eine nicht gefundene Assembly verweist. Dies kann passieren, wenn die Baugruppe aus einem anderen Projekt stammt, das nicht Teil Ihrer Lösung ist, aber sein sollte. In diesem Fall wird es einfach durch Hinzufügen des richtigen Projekts zur Lösung gelöst.

Überprüfen Sie den Abschnitt Referenzen jedes Projekts in Ihrer Lösung. Wenn einer von ihnen eine Referenz mit einem roten x daneben hat, haben Sie Ihr Problem gefunden. Diese Baugruppenreferenz kann von der Lösung nicht gefunden werden.

Die Fehlermeldung ist etwas verwirrend, aber ich habe das schon oft gesehen.

Blut
quelle
2
In meinem Fall war es eine "gelbe Warnung"
AXMIM
26

Wenn Sie WiX verwenden, sehen Sie sich dies an (es liegt ein Fehler vor) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

Manchmal werden der .wixprojDatei weiter unten in der Datei neue Build-Konfigurationen hinzugefügt, dh durch andere nicht verwandte XML-Elemente von ihren Geschwisterkonfigurationsdefinitionen getrennt.

Bearbeiten Sie die .wixprojDatei einfach so, dass alle <PropertyGroup>Abschnitte, die Ihre Build-Konfigurationen definieren, nebeneinander liegen. (Um das .wixprojin VS2013 zu bearbeiten, klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, Projekt entladen, klicken Sie erneut mit der rechten Maustaste-> Bearbeiten Sie YourProject.wixproj. Laden Sie es nach dem Bearbeiten der Datei neu.)

George
quelle
1
Danke, das hat es für mich behoben. Ich hatte viel seltsames Verhalten, je mehr Konfigurationen ich dem Projekt hinzufügte. Sobald ich die Projektdatei bereinigt hatte, funktionierte alles einwandfrei. (Dieser Fehler wurde erstmals im Jahr 2012 gemeldet?
Großartig
Danke, das hat es auch für mich
behoben
15

Dies geschah mir, weil ich die folgende Zeile nahe an den Anfang der .csproj-Datei verschoben hatte:

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>

Es muss hinter den PropertyGroups platziert werden, die Ihre Konfiguration | Plattform definieren.

Philip Atz
quelle
11

Der in Visual Studio für das Projekt angezeigte Fehler (sagen wir A) hat keine Probleme. Als ich das Ausgabefenster für den Build Zeile für Zeile für jedes Projekt betrachtete, stellte ich fest, dass es sich über ein anderes Projekt (B) beschwerte, das in Projekt A als Assembly bezeichnet wurde. Projekt B wurde der Lösung hinzugefügt. Es wurde jedoch in Projekt A nicht als Projektreferenz, sondern als Baugruppenreferenz von einem anderen Standort aus bezeichnet. Dieser Speicherort enthält die Assembly, die für Platform AnyCpu kompiliert wurde. Dann habe ich die Baugruppenreferenz aus Projekt A entfernt und Projekt B als Referenz hinzugefügt. Es begann zu kompilieren. Ich bin mir jedoch nicht sicher, wie dieses Update funktioniert hat.

Amzath
quelle
15
Versuchen Sie es auf jeden Fall mit \ p: Platform = "AnyCPU" anstelle von \ p: Platform = "Any CPU". Das hat bei mir funktioniert! Sah das schon ewig an!
Lee Englestone
AnyCPU (ohne Leerzeichen) hat auch für mich funktioniert. Danke Lee.
Willem
1
Beim Ausführen eines Erstellungsprozesses unter TFS 2017 ist der Fehler aufgetreten, nachdem ich den "Pfad zur Lösung oder packages.config" von ".sln" in ".vbproj" geändert habe. Das Ändern der BuildPlatform in AnyCPU hat auch bei mir funktioniert. Siehe den Hinweis unter "Plattform" hier: docs.microsoft.com/en-us/vsts/build-release/tasks/build/…
Mr.Zzyzzx
2
In meinem Fall war beim Starten des "any cpu"Builds über TFS der Standardwert für BuildPlatform. Ändern, um "AnyCPU"das Problem zu lösen.
XouDo
Dies ist 2020 - AnyCPU vs Any CPU ist immer noch ein Problemmacher. Ich verwende VS2019 und bekomme dies immer noch bei neuen Projekten. MS, warum bestrafen Sie die Entwicklergemeinde?
Christian
9

Ich habe den gleichen Fehler festgestellt, aber das Problem stellte sich heraus, weil ich in meiner Lösung eine neue Konfiguration erstellt hatte, die in referenzierten Assemblys einer anderen Lösung nicht vorhanden war.

Dies kann behoben werden, indem Sie die zugehörige Lösung öffnen und die neue Konfiguration hinzufügen.

Dieser Beitrag brachte mich auf die Idee, die referenzierten Assemblys zu überprüfen, nachdem ich bereits bestätigt hatte, dass alle Projekte in meiner Lösung die richtige Konfiguration hatten:

http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/

BK
quelle
7

hatte dieses Problem als Ausgabe von Azure DevOps nach dem Festlegen, dass die .csproj anstelle der .sln in der Build-Pipeline erstellt werden soll.

Die Lösung für mich: Bearbeiten Sie .csproj des betroffenen Projekts und kopieren Sie dann Ihr gesamtes

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCpu' ">

Knoten, fügen Sie es ein und ändern Sie dann die erste Zeile wie folgt:

    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|any cpu' ">

Der Grund ist, dass in meinem Fall der Fehler sagte

Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='release'  Platform='any cpu'.  

Warum Azure "jede CPU" anstelle der Standardeinstellung "AnyCpu" verwenden möchte, ist mir ein Rätsel, aber dieser Hack funktioniert.

Jens Caasen
quelle
Indem ich Ihrer Idee folgte, stellte ich fest, dass ich in meinem Fall keine Änderungen am Projekt vornehmen musste, sondern in meinem Visual Studio Build-Schritt in DevOps das Konfigurationsfeld so einrichtete, dass eine Variable mit dem AnyCpu-Wert verwendet wurde.
donatasj87
@ donatasj87 Würde es Ihnen etwas ausmachen, den vollen Wert dieses Feldes zu veröffentlichen?
Jay
1
Der volle Wert ist genau der gleiche, dies sollte auch im TFS-Build funktionieren. Es muss nur mit dem Wert übereinstimmen, der in Ihrer .csproj-Datei eingerichtet ist. Sie können es in diesem Bild sehen: pasteboard.co/JbdvBT5.png
donatasj87
4

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.

Lukas Dvorak
quelle
3

Ich habe:

  1. Klicken Sie mit der rechten Maustaste auf Projekt mit Problem -> Projekt entladen
  2. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie Bearbeiten * .csproj
  3. Kopieren Sie die Konfiguration aus der vorhandenen Konfiguration, die mit einem bestimmten Namen und einer bestimmten Zielplattform funktioniert (ich hatte Release | x64 ):

    <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
      <OutputPath>bin\x64\Release\</OutputPath>
      <DefineConstants>TRACE</DefineConstants>
      <Optimize>true</Optimize>
      <DebugType>pdbonly</DebugType>
      <PlatformTarget>x64</PlatformTarget>
      <ErrorReport>prompt</ErrorReport>
      <CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
      <Prefer32Bit>true</Prefer32Bit>
    </PropertyGroup>
  4. Klicken Sie mit der rechten Maustaste auf Projekt -> Projekt neu laden
  5. Projekt / Lösung neu erstellen
Janis S.
quelle
3

Wenn Sie diesen Fehler nur erhalten, wenn Sie versuchen, Ihr Projekt über die Befehlszeile mit MSBuild zu kompilieren (wie in meinem Fall), besteht die Lösung darin, den Ausgabepfad manuell mit einem Argument wie an MSBuild zu übergeben /p:OutputPath=MyFolder.

Anion
quelle
2

Eine weitere verrückte Möglichkeit: Wenn Sie einer einfachen Quellcodeverwaltungsanordnung folgen, indem Sie Branch \ Main, Main und Release nebeneinander platzieren und am Ende ein vorhandenes Projekt aus Main anstelle von Branch \ Main hinzufügen (vorausgesetzt, Ihre Arbeitslösung ist Branch \ Main), möglicherweise wird dieser Fehler angezeigt.

Die Lösung ist einfach: Referenzieren Sie das richtige Projekt!

Keith Hoffman
quelle
2

Ich bin auf dieses Problem gestoßen, als ich ein Projekt zu einer Lösung hinzugefügt und dann von einem anderen Projekt in derselben Lösung referenziert habe. Das gelbe Warnsymbol über der Referenz wurde angezeigt. Beachten Sie, dass der Pfad leer war.

Die Lösung ähnelte der von @Amzath vorgeschlagenen, meine Projekte wurden mit verschiedenen Ziel-Frameworks kompiliert, z. .NET 4.0 vs 4.5.

StuTheDog
quelle
2

In meinem Fall wurde die erstellte Adresse meiner App auf einen anderen Computer eingestellt, der ausgeschaltet war, also habe ich ihn eingeschaltet und VS neu gestartet und das Problem behoben.

Jesus Manuel
quelle
2

Eine weitere Ursache: Sie fügen in Lösung X eine Projektreferenz von Projekt A zu Projekt B hinzu. Die Lösung Y, die bereits Projekt A enthält, ist jetzt jedoch fehlerhaft, bis Sie auch Projekt B zu Lösung Y hinzufügen.

David White
quelle
2

Ich hatte das gleiche Problem, nachdem ich neue Konfigurationen hinzugefügt und die Konfigurationen "Debug" und "Release" gelöscht habe. In meinem Fall habe ich eine Cmd-Datei verwendet, um den Erstellungs- und Veröffentlichungsprozess auszuführen, aber der gleiche Fehler wurde ausgelöst. Die Lösung für mich: In der csproj-Datei Folgendes:

<Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>

hat die Konfiguration auf "Debug" gesetzt, wenn ich keine explizite angegeben habe. Nachdem ich den Knotenwert von "Debug" in meine benutzerdefinierte Konfiguration geändert hatte, funktionierte alles reibungslos. Hoffe das hilft auch wer auch immer das liest :)

MihaiB
quelle
Details zu dieser Lösung werden in diesem Forumsbeitrag erwähnt. social.msdn.microsoft.com/Forums/vstudio/en-US/…
Sunny Tambi
2

Ich hatte das gleiche Problem. Bearbeiten Sie einfach die .wixproj, um alle zu haben <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > Elemente nebeneinander werden.

Das hat mein Problem gelöst

Sharon
quelle
1

Das von mir verwendete WiX-Projekt war im Konfigurationsmanager auf breiter Front fest eingestellt x64. Beim Erstellen des benutzerdefinierten Aktionsprojekts für die Lösung wurde standardmäßig alles in x86der .csprojDatei verwendet. Also habe ich das Projekt entladen, es bearbeitet, indem ich alles x86in x64geändert, gespeichert, neu geladen und war gut darin, danach zu gehen.

Ich verstehe nicht, warum ich das tun musste. Der Konfigurationsmanager wurde als x64 erstellt, wurde jedoch nicht in der csprojDatei festgelegt :(

kayleeFrye_onDeck
quelle
0

Nachdem ich alle anderen hier veröffentlichten Vorschläge ausprobiert hatte, stellte ich fest, dass die Lösung für mich darin bestand, den folgenden Abschnitt aus der .csprojDatei zu entfernen :

  <ItemGroup>
    <Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
  </ItemGroup>

Anscheinend hat dieser Dienst aus dem ursprünglichen Projekt (auf dem lokalen Computer nicht verfügbar) den gesamten Erstellungsprozess angehalten, obwohl er für die Kompilierung nicht unbedingt erforderlich war.

Spezielle Sauce
quelle
0

Ich habe dieses Problem, nachdem ich meinem Projekt eine neue Plattform hinzugefügt habe. In meinem Fall befand sich die .csproj-Datei unter der Perforce-Quellcodeverwaltung und war schreibgeschützt. Ich habe es ausgecheckt, aber VS hat die Änderung erst erkannt, als ich sie neu gestartet habe.

Flot2011
quelle
0

Ich hatte ein ähnliches Problem bei einem Xamarin-Projekt. Es ist vielleicht ein seltener Fall, aber falls jemand anderes das Problem hat. Meine Projektstruktur war wie folgt

  • Das xamarin.Android-Projekt hatte eine Referenz aus dem xamarin.android.library-Projekt.
  • Ich habe ein Plugin mit Code aus dem android.library-Projekt erstellt.
  • Hier ist das Problem. Wenn Sie eine Projektreferenz oder eine Nuget-Installation für das Bibliotheksprojekt xamarin.android hinzufügen. Sie erhalten diesen Fehler. Entwickler gehen davon aus, dass sich der Code im Android.Library-Projekt befand und ich auf das neue Plugin in diesem Projekt verweisen muss. NEIN!
  • Sie müssen eine Referenz zum Haupt-Android-Projekt hinzufügen. weil Plugin-> Bibliothek-> Hauptprojektausgabe nicht erzeugt wird.
Batmaci
quelle