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

90

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.

laconicdev
źródło
6
Zmagałem się z tym przez wiele godzin, aż zdałem sobie sprawę, że lista rozwijana w definicji kompilacji TFS zawiera „Dowolny procesor” zamiast „AnyCPU” !!!!
The Muffin Man
1
W VS2012 menu rozwijane w konfiguracji kompilacji to „Dowolny procesor”, ale w pliku .csproj znajduje się „AnyCPU”, więc w Jenkins lub wierszu poleceń będzie działać opcja „AnyCPU”.
Jirong Hu

Odpowiedzi:

94

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.

Sayed Ibrahim Hashimi
źródło
33
Jeśli ścieżka wyjściowa jest poprawna i nadal otrzymujesz ten błąd, możesz mieć odwołania do zestawów lub innych projektów, które już nie istnieją. Wyczyść stare odniesienia. To było moje doświadczenie.
John K
3
Właśnie natknąłem się na ten błąd i musiałem bezpośrednio zmodyfikować plik projektu. Mimo że strona właściwości projektu zawierała informację „Dowolny procesor”, właściwość była początkowo ustawiona na pustą i wybrałem ustawienie Platform = BPC ze zmiennych środowiskowych. Po naprawieniu tego i ustawieniu / zresetowaniu strony właściwości z dowolnego procesora na x86 iz powrotem, nadal nie mógł się kompilować, twierdząc, że platforma była teraz `` x86 '' (?!?). Rzeczywiście, podążyłem za krokami tutaj i stwierdziłem, że jest teraz ustawiony na x86, więc ręcznie zmodyfikowałem go i teraz wszyscy są znowu szczęśliwi. Dzięki chłopaki!
DaveN59
2
Mój plik projektu miał oczekiwaną PropertyGroup z niepustą ścieżką OutputPath i otrzymywałem ten błąd. Jedyną rzeczą, jaką zauważyłem, było to, że PropertyGroup dla tej konkretnej konfiguracji była pierwszym elementem w węźle głównym w pliku, a atrybut warunku nie miał spacji wiodącej i końcowej, w przeciwieństwie do wszystkich innych warunków konfiguracji. W tym momencie przeniosłem ten element poniżej niektórych innych konfiguracji (nie jestem pewien, dlaczego miałoby to znaczenie, po prostu próbowałem rzeczy) i dodałem spację w warunku. Potem zadziałało. Nie jestem pewien, co spowodowało różnicę.
Seth Flowers
2
Miałem inny problem. Użyłem SlowCheetah do stworzenia moich transformacji konfiguracji dla mojego projektu Windows. Konfiguracje nie miały białych znaków, jak sugerował @sethflowers. Dodałem te, ale to nie pomogło. Zauważyłem, że między konfiguracjami była inna grupa właściwości. Więc to uporządkowałem (po prostu umieściłem grupę właściwości poniżej grup właściwości konfiguracji projektu) i problem zniknął. Dzięki za wszystkie sugestie tutaj. Zaoszczędziło mi to czasu !!!
LockTar
7
Deffo spróbuj z \ p: Platform = "AnyCPU" zamiast \ p: Platform = "Any CPU". U mnie to zadziałało! Patrzyłem na to od wieków!
Lee Englestone,
78

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).

Richard Dingwall
źródło
5
Napotkałem ten sam problem, wygląda na to, że na poziomie rozwiązania „Any CPU” jest poprawne, ale na poziomie projektu jest to „AnyCPU”. Innymi słowy, msbuild myproj.sln /p:Configuration=Debug /p:Platform="Any CPU"było w porządku, jednak podczas budowania projektu musiałem pominąć spację w dowolnym procesorze: msbuild myproj.proj1.csproj /p:Configuration=Debug /p:Platform=AnyCPUaby stłumić błąd właściwości Outputpath.
Emil G
2
Niewiarygodne i co za PITA dla konfiguracji CI. Walczę z tym od dni.
Jeremy Holovacs
Wystąpił ten błąd, gdy nie mogłem budować na głównym serwerze kompilacji, a alternatywny, który wybrałem, przeszedł „Dowolny procesor” zamiast „AnyCPU”. Po sprawdzeniu pojawiły się różnice w numerach wersji MSBUILD i innego oprogramowania. Dziękuję za odpowiedź,
Gilles
1
Nie mogę uwierzyć, że przyczyną była przestrzeń!
Alexandra
36

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.
Peter Mortensen
źródło
To rozwiązało mój problem z kompilacją TeamCity Azure Cloud Service. +1
starmandeluxe
Podobnie dla mnie z budową CI VSO.
StriplingWarrior
11

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.

Boggin
źródło
To złapało mnie na moim nowym laptopie HP - dzięki @Boggin - nie przyszłoby mi to do głowy.
Rob Cooper
9

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

Usuń tego złego chłopca.

Teraz uruchom ponownie program Visual Studio i gotowe.

Scott S.
źródło
6

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

Robert Hoffmann
źródło
6

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

OlegMax
źródło
Ten był związany z moim problemem, dodałem nową konfigurację do projektu wix po jego utworzeniu, a nowa konfiguracja została dodana na końcu pliku, więc wszystkie powiązane PropertyGroups z tą nową konfiguracją zostały umieszczone PO imporcie, przenosząc je do u góry, tuż obok pozostałych, działało dla mnie.
Eugenio Miró
4

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

cierń
źródło
1
Niestety, nawet po usunięciu zmiennej środowiskowej Platforma wymaga pełnego ponownego uruchomienia!
79E09796
4

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>
Gustavo Mori
źródło
3

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.

Glenn
źródło
3

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 ...

M Denis
źródło
To zadziałało, gdy usunąłem platformę, którą określiłem w moim kroku Build vNext MSBuild.
4imble
2

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.

laconicdev
źródło
1
Napotkałem ten sam błąd i to obejście było jedyną rzeczą, która zadziałała. Zasadniczo miałem konfigurację platformy rozwiązania „Win32”, która tworzy projekt Silverlight z konfiguracją platformy „Dowolny procesor”, a także projekt aplikacji internetowej z konfiguracją platformy „x86”, która obsługuje projekt Silverlight. Musiałem dodać nową konfigurację platformy projektu do projektu Silverlight, „x86” (i zachować starą jako konfigurację domyślną), aby msbuild działał zgodnie z oczekiwaniami.
Rami A.
2

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.

Gishe
źródło
2

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.

Tomasz Stypich
źródło
1

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.

farkashon
źródło
1

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.

BNJ
źródło
0

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.

Aleksandra Pawlenko
źródło
0

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ął.

Ike
źródło
0

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.

Lukas Dvorak
źródło
0

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

Marysia
źródło
0

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

user5920105
źródło
0

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.

squadwuschel
źródło
0

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.

pmeyer
źródło
0

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.

Waescher
źródło
0

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.

ermenegild0
źródło
0

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!)

Etherman
źródło
0

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).

Martin Maat
źródło