Błąd „właściwość outputpath nie jest ustawiona dla tego projektu”

Mam rozwiązanie obsługujące wiele projektów w programie Visual Studio 2008. Właśnie dodałem do rozwiązania nową konfigurację o nazwie Release-VersionIncrement, określając konfigurację „użyj wersji” jako podstawę. Wszystkie pliki projektu zostały zaktualizowane przy użyciu tej konfiguracji. Jednak gdy próbuję skompilować określony projekt przy użyciu tej konfiguracji, pojawia się następujący błąd:

Błąd 5 Właściwość OutputPath nie jest ustawiona dla tego projektu. Sprawdź, czy określono prawidłową kombinację konfiguracji i platformy. Configuration = 'Release-VersionIncrement' Platform = 'AnyCPU' C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ Microsoft.Common.targets 539 9 DataConversion

Co tu się dzieje? Projekt kompiluje się dobrze w konfiguracji wydania lub debugowania.

Zwykle dzieje się tak, gdy właściwość OutputPath pliku projektu jest pusta. Pliki projektów to tylko pliki MSBuild . Aby edytować w Visual Studio: Kliknij prawym przyciskiem myszy projekt, wybierz „Zwolnij projekt”, a następnie kliknij prawym przyciskiem myszy zwolniony projekt i wybierz „Edytuj ...”.

Poszukaj grupy właściwości Release-Versionincrement. Powinien wyglądać jak

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release-VersionIncrement|AnyCPU' ">
  <OutputPath>bin\Release-VersionIncrement\</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <Optimize>true</Optimize>
  <DebugType>pdbonly</DebugType>
  <PlatformTarget>AnyCPU</PlatformTarget>
  <CodeAnalysisUseTypeNameInSuppression>true</CodeAnalysisUseTypeNameInSuppression>
  <CodeAnalysisModuleSuppressionsFile>GlobalSuppressions.cs</CodeAnalysisModuleSuppressionsFile>
  <ErrorReport>prompt</ErrorReport>
</PropertyGroup>

Ważny jest plik OutputPath, czy istnieje dla pliku projektu? Jeśli nie, dodaj go i spróbuj ponownie.

Widziałem również ten błąd, gdy nasz agent kompilacji został skonfigurowany do uruchamiania platformy „ Dowolny procesor ” (ze spacjami wyświetlanymi w programie Visual Studio), a nie „ AnyCPU ” (jedno słowo określone w pliku projektu).

Miałem ten sam problem, gdy najpierw użyłem MSBuild. Moje rozwiązanie to: zdecydowanie użyj właściwości OutputPath. Lubię to:

msbuild XXX.csproj /p:OutputPath=bin\Debug.

W naszym przypadku uruchomiliśmy skrypt kompilacji na naszych komputerach programistycznych HP. HP ma kilka zmiennych środowiskowych, które ustawili do własnych celów, a jedną z nich jest PLATFORMA (używana najwyraźniej w „HP Easy Setup”).

Usunięcie zmiennej środowiskowej PLATFORM działało.

Możesz również przygotować skrypt kompilacji na przyszłość, określając platformę, tj
msbuild /p:Platform=AnyCPU.

Jeśli program Visual Studio wyraźnie narzeka, że ​​„Platform = 'BPC' '”, możesz łatwo to naprawić, usuwając zmienną środowiskową „Platform”.

Teraz uruchom ponownie program Visual Studio i gotowe.

Jak zasugerował „ Richard Dingwall ”, problem jest związany z VS korzystającym z wyświetlanej wersji „ Any CPU ” zamiast wersji MSBuild, która faktycznie czyta „ AnyCPU ”

Przejdź do opcji Build / New Build Definition lub Edit Build Definition -> Process -> Configurations to build, otwórz okno dialogowe wyboru konfiguracji iw „ Platform ” zamiast wybierać „ Any CPU ”, ręcznie dodaj „ AnyCPU ”

Jak zostało powiedziane, OutputPath musi być ustawione ORAZ musi być umieszczone wcześniej <Import Project="$(WixTargetsPath)" /> w pliku .wixproj

Usunąłem Platformzmienną środowiskową (było BNB lub coś takiego). Problem zniknął.

Dodawałem dzisiaj platformę x64 do mojego rozwiązania, kiedy napotkałem ten problem.

W moim przypadku błąd brzmiał:

Zbudowano $ / ProjectDirectory / ProjectName.csproj dla domyślnych celów. c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets (484): Właściwość OutputPath nie jest ustawiona dla projektu ProjectName.csproj '. Sprawdź, czy dla tego projektu określono prawidłową kombinację konfiguracji i platformy. Konfiguracja = „Debuguj” Platforma = „x64”. Ten komunikat może być wyświetlany, ponieważ próbujesz skompilować projekt bez pliku rozwiązania i określono inną niż domyślną konfigurację lub platformę, która nie istnieje dla tego projektu.

Wiedziałem, że OutputPathpowinno być dobrze, ponieważ było to istniejące, działające rozwiązanie VS. Więc przeszedłem do następnej wskazówki - „poprawne połączenie konfiguracji i platformy”.

Aha! Program Visual Studio próbuje skompilować Configuration='Debug', Platform='x64'. Patrząc na mój plik projektu, zdałem sobie sprawę, że x64 nie jest wymieniony jako jedna z możliwych platform. Innymi słowy, miałem poniższe wpisy (skrócone):

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
      <PlatformTarget>x86</PlatformTarget>
      <OutputPath>bin\x86\Debug\</OutputPath>  
      . . .  
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
      <PlatformTarget>x86</PlatformTarget>
      <OutputPath>bin\x86\Release\</OutputPath>    
      . . .
  </PropertyGroup>

Łatwo więc naprawić: po prostu dodaj wpisy x64!

Skopiowałem / wkleiłem wpisy x86 i zmieniłem je, aby używały x64. Zauważ, że zmodyfikowałem również ścieżki, aby nie nadpisywały one kompilacji x86:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
      <PlatformTarget>x64</PlatformTarget>
      <OutputPath>bin\x64\Debug\</OutputPath>    
      . . .
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
      <PlatformTarget>x64</PlatformTarget>
      <OutputPath>bin\x64\Release\</OutputPath>    
      . . .
  </PropertyGroup>

Przez chwilę się z tym zmagałem, a potem też wyładowałem, zbudowałem, a potem przeładowałem w rozwiązaniu problematyczny projekt, po czym MSBuild działał poprawnie.

Jako Scott S musiałem usunąć zmienną środowiskową „Platforma” .

Następnie uruchom ponownie VS i wszystko jest w porządku: nie ma już komunikatu o błędzie ...

Problem dotyczył konfiguracji mojego projektu. Oto scenariusz:

Rozwiązanie A odwołuje się do:

Projekt X odnosi się do Projektu Y
Projekt Y

Rozwiązanie B (to, które próbuję zbudować) odniesienia:

Projekt X Projekt Z

Moim rozwiązaniem było utworzenie konfiguracji o tej samej nazwie dla rozwiązania A, odbudowanie jej, a następnie odbudowanie rozwiązania B. To rozwiązało problem.

Miałem ten sam komunikat o błędzie. Było to spowodowane posiadaniem odwołania do projektu, który został wyładowany i nie był wymagany przez konsolidator (w przeciwnym razie nie powiodło się w czasie kompilacji). Usunięcie naruszającego odniesienia rozwiązało problem.

W moim przypadku (VS2010) usunąłem ciąg w polu „OutputPath” znajdującym się na karcie „Build” i pozostawiłem go pustym. Następnie odbudowałem rozwiązanie. Kompilacja powiodła się i program VS wstawił bieżący katalog „./” do „OutputPath”. Zastąpiłem bieżący katalog „./” moją ścieżką („bin \ x64 \ Release \” - wystarczy powiedzieć, że jest to dokładna ścieżka folderu, na który narzekał VS) i odbudowanie zakończyło się powodzeniem.

W moim przypadku właściwość OutputPath została ustawiona w plikach projektu. Ale rozładowanie, ponowne załadowanie, a następnie odbudowanie naprawiło to.

Gdy dodałem nową konfigurację rozwiązania do mojego rozwiązania, pojawił się błąd „Właściwość OutputPath nie jest ustawiona dla projektu X. Sprawdź, czy określono poprawną kombinację konfiguracji i platformy dla tego projektu. Configuration = 'QA „Platforma =„ AnyCPU ”. Ten błąd może się również pojawić, jeśli inny projekt próbuje podążać za odniesieniem między projektami do tego projektu, ten projekt został usunięty lub nie jest uwzględniony w rozwiązaniu, a projekt, do którego się odwołuje, nie budować przy użyciu tej samej lub równoważnej konfiguracji lub platformy ”.

W moim przypadku problem wynikał z podświetlenia części opisu błędu. Część projektu X mojego rozwiązania miała odniesienie projektu do ProjectY innego rozwiązania (innej gałęzi).

Rozwiązałem ten problem, modyfikując projekt X, aby w obecnym rozwiązaniu używał odniesienia do projektu do ProjectY. Mam nadzieję, że pomoże to komuś, kto ma podobny problem.

W moim przypadku nowy blok XML „PropertyGroup” został wygenerowany na dole dokumentu. Właśnie zastąpiłem go innymi tagami „PropertyGroup” i to rozwiązało problem.

Stworzyłem nowy projekt w nowym rozwiązaniu, które nawiązuje do istniejących projektów. Ten błąd występuje, gdy dodaję istniejący projekt (powiedzmy projekt 1) i próbuję zbudować bez dodawania innych projektów, do których odwołuje się projekt 1.

Po prostu upewnij się, że wszystkie powiązane projekty zostały dodane do nowego rozwiązania, a błąd zniknął.

Miałem ten sam błąd, więc spojrzałem na ustawienia projektu i tam w sekcji „Build” jest opcja „Build output path”. A wartość była pusta. Więc podałem wartość "bin \" błąd zniknął. To rozwiązało mój problem.

Jeśli zdecydujesz się ustawić OutputPath jako parametr, a twoja ścieżka jest taka: bin\Release\\to pamiętaj, aby dodać \na końcu w ten sposób: /p:OutputPath=bin\Release\\\\zajęło mi trochę czasu, zanim zdałem sobie sprawę, że tak jest

Miałem ten sam problem. Naprawiłem to przez wyczyszczenie i przebudowanie projektów.

Miałem ten sam problem i jedynym rozwiązaniem, które pomogło, było ręczne ustawienie konfiguracji kompilacji w każdym projekcie NCrunch.

Otwórz okno NCrunch, w którym możesz zobaczyć stan każdej kompilacji i gdzie możesz zobaczyć, że kompilacja kończy się niepowodzeniem. Kliknij prawym przyciskiem myszy projekt, który się nie buduje i kliknij „Konfiguruj wybrany komponent”, który zobaczysz w „Ustawieniach kompilacji”, właściwość „Użyj konfiguracji kompilacji” ustaw ją na np. „Debuguj”, a właściwość „Użyj platformy kompilacji” ustaw ją na np. „AnyCPU”. (Pamiętaj, że ustawienia kompilacji i konfiguracji, które ustawiłeś, muszą istnieć w ustawieniach konfiguracji)

Zrób to dla wszystkich swoich projektów, ale nie dla projektu testowego. Po tym wszystko u mnie dobrze działa.

Miałem ten sam problem, naprawiłem go, dodając brakujące konfiguracje do projektu, który uległ awarii.

BUILD -> Configuration Manager ->

W kolumnie konfiguracji Dodaj

Uwaga: stało się tak tylko dlatego, że mam konfigurację niestandardową, a nowo utworzone projekty nie miały takiej konfiguracji.

Jeśli ktoś otrzymuje ten w swoich dziennikach NCrunch, sprawdź, czy PropertyGroupzdefiniowane wartości „Debug” / „Release” i „AnyCPU” / „x86” znajdują się przed grupami właściwości używającymi tych wartości w ich stanie.

<PropertyGroup>
    <!-- this one first -->
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <XXX>...</XXX>
  </PropertyGroup>

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <XXX>...</XXX>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <XXX>...</XXX>
</PropertyGroup>

Pracował dla mnie.

W moim przypadku próbowałem przenieść grupę właściwości, która zawierała moją konfigurację niestandardową, poniżej standardowych. Rozwiązało to dla mnie.

Właśnie to miałem z VS2015 Professional:

Właściwość OutputPath nie jest ustawiona dla projektu „xxxxx.csproj”. Sprawdź, czy dla tego projektu określono prawidłową kombinację konfiguracji i platformy.

Jest to również żonglowanie wieloma projektami między debugowaniem / wydaniem a różnymi celami. W pewnym momencie majstrowałem przy konfiguracjach kompilacji i wiem, że może to zepsuć VS, więc wycofałem je z repozytorium. Nadal nie jest dobrze. OutputPath został ustawiony, nie było już żadnych różnic o znanym dobrym stanie, więc zdecydowanie coś było nie tak z moją lokalną instalacją.

Otworzyłem instalator VS2015 i kliknąłem „Napraw” i voila… z powrotem do normalności (przynajmniej na razie!)

Dla mnie była to linia w konfiguracji pakietu NuGet. Pozbądź się wszystkich pakietów związanych z plikiem projektu i zobacz, jak ożyją (zapisz zmiany). Następnie buduj to ponownie część po części. Sprowadziłem to do tej linii, którą musiałem usunąć:

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

Problem pojawił się po aktualizacji pakietów NuGet (głównie analizatora FxCop).