webentwicklung-frage-antwort-db.com.de

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

Wenn ich versuche, mein Projekt aus dem x86-Debug-Modus in Visual Studio 2008 zu kompilieren, wird diese Fehlermeldung angezeigt. Wenn ich mir die Eigenschaftsgruppe des beanstandeten Projekts ansehe, sehe ich einen Ausgabepfad.

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 darauf werfen?

HINWEIS: Wenn ich dieses Debugging und eine beliebige CPU kompilierte, funktionierte es.

UPDATED: Error 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' 

87
Amzath

Der in Visual Studio für das Projekt angezeigte Fehler (Angenommen, A) hat keine Probleme. Als ich für jedes Projekt das Ausgabefenster Zeile für Zeile sah, bemerkte ich, dass es über ein anderes Projekt (B) klagte, das im Projekt A als Assembly bezeichnet wurde. Es wurde im Projekt A jedoch nicht als Projektreferenz, sondern als Montagereferenz von einem anderen Ort aus bezeichnet. Dieser Speicherort enthält die Assembly, die für Platform AnyCpu erstellt wurde. Dann entfernte ich die Assembly-Referenz aus dem Projekt A und fügte Projekt B als Referenz hinzu. Es begann zu kompilieren. Nicht sicher, wie dieser Fix funktionierte.

8
Amzath

Hatte genau den gleichen Fehler nach dem Hinzufügen einer neuen Konfiguration über ConfigurationManager in VisualStudio.

Es stellte sich heraus, dass die 'Production'-Konfiguration für die gesamte Lösung (und jedes Projekt) hinzugefügt wurde. Das OutputPath-Element war nicht wurde den csproj-Dateien hinzugefügt.

Um dieses Problem zu beheben, bin ich auf die Registerkarte "Erstellen" der Projekteigenschaften gegangen, habe OutputPath von \bin\Production\ in \bin\Production geändert (gelöschter nachfolgender \) und die Änderungen gespeichert. Diese erzwungene Erstellung des OutputPath-Elements in der csproj-Datei und im Projekt wurde erfolgreich erstellt.

Hört sich für mich wie eine Panne an.

139
Roman Gudkov

Sie können diesen Fehler in VS 2008 sehen, wenn sich in Ihrer Lösung ein Projekt befindet, das auf eine Assembly verweist, die nicht gefunden werden kann. Dies kann passieren, wenn die Assembly aus einem anderen Projekt stammt, das nicht Teil Ihrer Lösung ist, aber sein sollte. In diesem Fall lösen Sie einfach das richtige Projekt, um die Lösung zu lösen.

Überprüfen Sie den Abschnitt "Referenzen" jedes Projekts in Ihrer Lösung. Wenn einer von ihnen einen Verweis mit einem roten X daneben hat, dann haben Sie Ihr Problem gefunden. Diese Assembly-Referenz kann von der Lösung nicht gefunden werden.

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

26
dblood

Wenn Sie WiX verwenden, schauen Sie sich das an (es gibt einen Fehler) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

Manchmal werden neue Build-Konfigurationen der .wixproj-Datei weiter unten in der Datei hinzugefügt, d. H. Sie werden von ihren gleichgeordneten Konfigurationsdefinitionen durch andere, nicht zusammenhängende XML-Elemente getrennt.

Bearbeiten Sie einfach die .wixproj-Datei, sodass alle <PropertyGroup>-Abschnitte, die Ihre Build-Konfigurationen definieren, nebeneinander liegen. (Um den .wixproj in VS2013 zu bearbeiten, klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt. Projekt entladen, klicken Sie erneut mit der rechten Maustaste -> Edit YourProject.wixproj. Nach dem Bearbeiten der Datei erneut laden.)

22
george

Ich bin auf den gleichen Fehler gestoßen, aber es stellte sich heraus, dass ich in meiner Lösung eine neue Konfiguration erstellt hatte, die in referenzierten Assemblys aus einer anderen Lösung nicht vorhanden war.

Sie können dies beheben, indem Sie die zugehörige Lösung öffnen und die neue Konfiguration ebenfalls 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/

9
B-K

Dies passierte 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 Configuration | Platform definieren.

4
Philip Atz

Ich hatte den gleichen Fehler, also habe ich nach Projekteinstellungen gesucht und dort im Abschnitt "Build" die Option "Ausgabepfad erstellen". Und der Wert war leer. Also habe ich "bin \" eingegeben und ein Fehler ist verschwunden. Es hat mein Problem gelöst.

3
Lukas Dvorak

Dieses Problem trat auf, als ich ein Projekt zu einer Lösung hinzufügte und es von einem anderen Projekt in derselben Lösung referenzierte. Das gelbe Warnsymbol wurde über der Referenz angezeigt.

Die Lösung ähnelte der von @Amzath vorgeschlagenen Lösung. Meine Projekte wurden mit verschiedenen Target Frameworks erstellt, z. .NET 4.0 vs. 4.5.

2
StuTheDog

Eine andere verrückte Möglichkeit: Wenn Sie einer einfachen Anordnung der Quellcodeverwaltung folgen, indem Sie Branch\Main, Main und Release nebeneinander stellen und am Ende ein bestehendes Projekt aus Main anstelle von Branch\Main hinzufügen (vorausgesetzt, Ihre Arbeitslösung ist gegeben) ist Branch\Main), können Sie diesen Fehler sehen.

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

2
Keith Hoffman

Ich hatte das gleiche Problem, nachdem ich neue Konfigurationen hinzugefügt und die "debug" - und "release" -Konfigurationen gelöscht hatte .. In meinem Fall verwendete ich eine cmd-Datei, um den Build- und Publish-Prozess auszuführen, aber der gleiche Fehler wurde ausgegeben. Die Lösung für mich: In der csproj-Datei folgendes:

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

habe die Konfiguration auf "Debug" gesetzt, wenn ich keine explizite angegeben habe. Nachdem der Knotenwert von "debug" in meine benutzerdefinierte Konfiguration geändert wurde, funktionierte alles reibungslos. Hoffe, das wird auch helfen, wer das liest :)

2
MihaiB

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

2
anion

In meinem Fall war die Adresse meiner App auf einen anderen Computer eingestellt, der ausgeschaltet war, also habe ich VS eingeschaltet und VS neu gestartet und das Problem gelöst.

2
Jesus Manuel

Ich habe:

  1. Klicken Sie mit der rechten Maustaste auf Projekt mit Ausgabe -> Projekt entladen
  2. Rechtsklick auf Projekt und wähle Edit * .csproj  
  3. Kopieren Sie die Konfiguration aus der vorhandenen Konfiguration, die mit dem spezifischen Namen und der 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. Rechtsklick Projekt -> Projekt neu laden
  5. Wiederherstellen Projekt/Lösung
1
Janis S.

Eine andere Ursache: Sie fügen Projekt A von Projekt A in Projektmappe X in Lösung X hinzu. Die Lösung Y, die bereits Projekt A enthält, ist jetzt jedoch fehlerhaft, bis Sie Projekt B ebenfalls in Lösung Y einfügen. 

1
David White

Ich hatte das gleiche Problem Bearbeiten Sie einfach das .wixproj, damit alle <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... >-Elemente nebeneinander stehen.

Das hat mein Problem gelöst

1
Sharon

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

0
Flot2011

Das WiX-Projekt, das ich verwendete, war im Konfigurationsmanager für x64 durchgängig festgelegt. Bei der Erstellung des benutzerdefinierten Aktionsprojekts für die Lösung wurde x86 in der .csproj-Datei als Standard festgelegt. Also habe ich das Projekt entladen, bearbeitet, indem ich alle x86 in x64 geändert habe, gespeichert und neu geladen habe, und es war gut, danach zu gehen.

Ich verstehe nicht, warum ich das tun musste. Der Konfigurationsmanager wurde so eingestellt, dass er als x64 erstellt wird, er wurde jedoch nicht in der csproj-Datei festgelegt :(

0

dieses Problem trat bei der Ausgabe von Azure DevOps auf, nachdem in der Build-Pipeline festgelegt wurde, dass die CSPROJ-Datei anstelle der SLN-Datei erstellt wird.

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 die erste Zeile wie folgt:

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

Der Grund ist, dass in meinem Fall der Fehler besagt

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 "any cpu" anstelle der Standardeinstellung "AnyCpu" verwenden möchte, ist mir ein Rätsel, aber dieser Hack funktioniert.

0
Jens Caasen

Nachdem ich alle anderen Vorschläge ausprobiert hatte, stellte ich fest, dass die Lösung darin bestand, den folgenden Abschnitt aus der .csproj-Datei zu entfernen:

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

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

0
Special Sauce