Właściwość OutputPath nie jest ustawiona dla tego projektu

Kiedy próbuję skompilować projekt z trybu debugowania x86 w programie Visual Studio 2008. Otrzymuję ten błąd. Kiedy spojrzałem na grupę właściwości projektu, który narzekał, widzę, że ścieżka wyjściowa jest ustawiona.

Oto sekcja grupy właściwości dla tego pliku .csproj

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

Czy ktokolwiek może rzucić na to światło?

UWAGA: Kiedy skompilowałem ten debug i dowolny procesor, zadziałało.

AKTUALIZACJA: Błąd 1 Właściwość OutputPath nie jest ustawiona dla tego projektu. Sprawdź, czy podałeś prawidłową kombinację Konfiguracja / Platforma. Konfiguracja = „Debuguj” Platforma = „x86”

Miałem dokładnie ten sam błąd po dodaniu nowej konfiguracji za pomocą ConfigurationManager w Visual Studio.

Okazało się, że po dodaniu konfiguracji „Production” dla całego rozwiązania (i każdego projektu) element OutputPath nie został dodany do plików .csproj.

Aby to naprawić, przeszedłem do zakładki Build we właściwościach projektu, zmieniłem OutputPath z \bin\Production\na \bin\Production(usunięte końcowe \) i zapisałem zmiany. To wymusiło utworzenie elementu OutputPath w pliku .csproj i projekt został pomyślnie skompilowany.

Dla mnie brzmi to jak usterka.

Ten błąd można zobaczyć w programie VS 2008, jeśli masz projekt w rozwiązaniu, który odwołuje się do zestawu, którego nie można znaleźć. Może się tak zdarzyć, jeśli zestaw pochodzi z innego projektu, który nie jest częścią Twojego rozwiązania, ale powinien. W takim przypadku po prostu dodanie poprawnego projektu do rozwiązania rozwiąże problem.

Sprawdź sekcję odwołania każdego projektu w rozwiązaniu. Jeśli któryś z nich ma odniesienie z czerwonym x obok niego, oznacza to, że znalazłeś problem. To odwołanie do zestawu nie może zostać znalezione przez rozwiązanie.

Komunikat o błędzie jest nieco zagmatwany, ale widziałem to wiele razy.

Jeśli używasz WiX, spójrz na to (jest błąd) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

Czasami nowe konfiguracje kompilacji są dodawane do .wixprojpliku w dalszej części pliku, to znaczy są oddzielane od ich siostrzanych definicji konfiguracji innymi niepowiązanymi elementami XML.

Po prostu edytuj .wixprojplik tak, aby wszystkie <PropertyGroup>sekcje definiujące konfiguracje kompilacji sąsiadowały ze sobą. (Aby edytować .wixprojw VS2013, kliknij prawym przyciskiem myszy projekt w Eksploratorze rozwiązań, Zwolnij projekt, kliknij ponownie prawym przyciskiem myszy -> Edytuj YourProject.wixproj. Załaduj ponownie po edycji pliku).

Zdarzyło mi się to, ponieważ przeniosłem następujący wiersz blisko początku pliku .csproj:

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

Musi być umieszczony po PropertyGroups, które definiują konfigurację | Platformę.

Błąd pokazany w Visual Studio dla projektu (powiedzmy A) nie ma problemów. Kiedy spojrzałem na okno wyjściowe dla budowania wiersz po wierszu dla każdego projektu, zauważyłem, że narzekał on na inny projekt (B), który został nazwany montażem w projekcie A. Projekt B został dodany do rozwiązania. Jednak w projekcie A nie było to odniesienie do projektu zamiast odniesienia do zestawu z innej lokalizacji. Ta lokalizacja zawiera zestaw skompilowany dla platformy AnyCpu. Następnie usunąłem odwołanie do zespołu z projektu A i dodałem projekt B jako odniesienie. Zaczęło się kompilować. Nie jestem pewien, jak działała ta poprawka.

Napotkałem ten sam błąd, ale okazało się, że problem polega na tym, że utworzyłem nową konfigurację w moim rozwiązaniu, która nie istniała w zestawach, do których istnieją odwołania z innego rozwiązania.

Można to rozwiązać, otwierając powiązane rozwiązanie i dodając do niego nową konfigurację.

Ten post dał mi pomysł, aby sprawdzić zestawy, do których się odwołałem, po tym, jak już potwierdziłem, że wszystkie projekty w moim rozwiązaniu mają poprawną konfigurację:

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

wystąpił ten problem jako dane wyjściowe z usługi Azure DevOps po ustawieniu kompilacji .csproj zamiast .sln w potoku kompilacji.

Rozwiązanie dla mnie: Edytuj .csproj projektu, którego dotyczy problem, a następnie skopiuj cały plik

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

Węzeł, wklej go, a następnie zmień pierwszą linię w następujący sposób:

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

Powodem jest to, że w moim przypadku powiedział błąd

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

Dlaczego Azure chce używać „dowolnego procesora” zamiast domyślnego „AnyCpu”, jest dla mnie tajemnicą, ale ten hack działa.

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 wpisałem wartość "bin \" błąd zniknął. To rozwiązało mój problem.

Mam:

1. Kliknij prawym przyciskiem myszy projekt, którego dotyczy problem -> Zwolnij projekt
2. Kliknij projekt prawym przyciskiem myszy i wybierz Edytuj * .csproj

3. Skopiuj i wklej konfigurację z istniejącej konfiguracji, która działa z określoną nazwą i platformą docelową (miałem Wydanie | 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. Kliknij prawym przyciskiem myszy projekt -> Wczytaj ponownie projekt
5. Przebuduj projekt / rozwiązanie

Jeśli pojawi się ten błąd tylko podczas próby skompilowania projektu z wiersza polecenia przy użyciu programu MSBuild (jak w moim przypadku), rozwiązaniem jest ręczne przekazanie ścieżki wyjściowej do programu MSBuild z argumentem takim jak /p:OutputPath=MyFolder.

Kolejna szalona możliwość: jeśli zastosujesz się do prostego układu kontroli źródła, polegającego na umieszczeniu gałęzi \ Main, Main i Release obok siebie i w jakiś sposób skończysz dodając istniejący projekt z Main zamiast Branch \ Main (zakładając, że działającym rozwiązaniem jest Branch \ Main), możesz zobaczyć ten błąd.

Rozwiązanie jest proste: odwołaj się do właściwego projektu!

Napotkałem ten problem podczas dodawania projektu do rozwiązania, a następnie odwoływania się do niego z innego projektu w tym samym rozwiązaniu - otrzymałem żółtą ikonę ostrzeżenia nad odniesieniem, zauważ, że ścieżka była pusta.

Rozwiązanie było podobne do tego, co zasugerował @Amzath, moje projekty były kompilowane z różnymi platformami docelowymi, np. .NET 4.0 vs 4.5.

W moim przypadku wbudowany adres mojej aplikacji został ustawiony na inny komputer, który był wyłączony, więc włączyłem go i ponownie uruchomiłem VS, a problem został rozwiązany.

Inna przyczyna: dodajesz odwołanie do projektu z projektu A do projektu B w rozwiązaniu X. Jednak rozwiązanie Y, które już zawiera projekt A, jest teraz zepsute, dopóki nie dodasz również projektu B do rozwiązania Y.

Miałem ten sam problem po dodaniu nowych konfiguracji i usunięciu konfiguracji „debugowania” i „wydania”. W moim przypadku użyłem pliku cmd do uruchomienia procesu kompilacji i publikacji, ale został zgłoszony ten sam błąd. Rozwiązanie dla mnie: w pliku csproj:

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

ustawiał konfigurację na „Debuguj”, jeśli nie określiłem jej jawnie. Po zmianie wartości węzła z „debug” na moją konfigurację niestandardową wszystko działało gładko. Mam nadzieję, że pomoże to również każdemu, kto to czyta :)

Miałem ten sam problem, po prostu wyedytuj plik .wixproj, aby wszystkie <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... >elementy były obok siebie.

To rozwiązało mój problem

Projekt WiX, którego używałem, był trudny do skonfigurowania w menedżerze konfiguracji dla x64wszystkich elementów. Tworząc projekt akcji niestandardowej dla rozwiązania, domyślnie wszystko x86znajdowało się w .csprojpliku. Więc wyładowałem projekt, zredagowałem go, zmieniając wszystko x86na x64, zapisałem, załadowałem ponownie i dobrze było po tym.

Nie rozumiem, dlaczego musiałem to zrobić. Menedżer konfiguracji został ustawiony na kompilację jako x64, ale po prostu nie został ustawiony w csprojpliku :(

Po wypróbowaniu wszystkich innych zamieszczonych tutaj sugestii odkryłem, że rozwiązaniem dla mnie jest usunięcie z .csprojpliku następującej sekcji :

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

Najwyraźniej ta usługa z oryginalnego projektu (niedostępna na komputerze lokalnym) zatrzymywała cały proces kompilacji, mimo że nie była niezbędna do kompilacji.

Mam ten problem po dodaniu nowej platformy do mojego projektu. W moim przypadku plik .csproj był pod kontrolą źródła Perforce i był tylko do odczytu. Sprawdziłem to, ale VS nie złapał zmiany, dopóki nie uruchomiłem go ponownie.

Miałem podobny problem w projekcie Xamarin. Jest to może rzadki przypadek, ale na wypadek, gdyby ktoś inny miał problem. struktura mojego projektu wyglądała jak poniżej

• Projekt xamarin.Android miał odwołanie z projektu xamarin.android.library.
• Stworzyłem wtyczkę używając kodu z projektu android.library.
• Teraz jest problem. jeśli dodasz odwołanie do projektu lub instalację nuget w projekcie biblioteki xamarin.android. Otrzymasz ten błąd. Deweloperzy zakładają, że kod znajdował się w projekcie Android.Library i muszę odwoływać się do nowej wtyczki w tym projekcie. NIE!
• musisz dodać odwołanie w głównym projekcie systemu Android. ponieważ wtyczka-> biblioteka-> główne wyjście projektu nie jest produkowane.