Властивість OutputPath для цього проекту не встановлено

Коли я намагаюся скомпілювати мій проект з режиму налагодження x86 у Visual Studio 2008. Я отримую цю помилку. Коли я переглянув групу властивостей проекту, який скаржився, я бачу, що встановлено шлях виводу.

Ось розділ групи властивостей для цього .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>

Чи може хтось пролити світло на це?

ПРИМІТКА. Коли я компілював цю налагодження та будь-який процесор, він працював.

ОНОВЛЕНО: Помилка 1 Властивість OutputPath для цього проекту не встановлено. Переконайтеся, що ви вказали дійсну комбінацію Конфігурація / Платформа. Configuration = 'Debug' Platform = 'x86'

У мене була точно така ж помилка після додавання нової конфігурації через ConfigurationManager у Visual Studio.

Виявилося, коли для цілого рішення (і кожного проекту) було додано конфігурацію «Виробництво», до файлів .csproj не було додано елемент OutputPath.

Щоб виправити, я перейшов на вкладку Build у властивостях проекту, змінив OutputPath з \bin\Production\на \bin\Production(видалене трейлінг \) та зберег зміни. Це примусове створення елемента OutputPath у файлі .csproj і проект успішно побудований.

Мені звучить глюк.

Ви можете побачити цю помилку в VS 2008, якщо у вашому рішенні є проект, який посилається на збірку, яку неможливо знайти. Це може статися, якщо збірка виходить з іншого проекту, який не є частиною вашого рішення, але повинен бути. У цьому випадку просто додавання правильного проекту до рішення вирішить його.

Перевірте розділ "Посилання" кожного проекту у своєму рішенні. Якщо будь-який з них має посилання з червоним x поруч, то саме ви знайшли свою проблему. Ця посилання на збірку не може бути знайдена рішенням.

Повідомлення про помилку трохи заплутане, але я бачив це багато разів.

Якщо ви використовуєте WiX, подивіться на це (є помилка) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

Іноді нові конфігурації збірки додаються до .wixprojфайлу далі за файлом, тобто відокремлюються від їх визначень конфігурації братів іншими неспорідненими елементами XML.

Просто відредагуйте .wixprojфайл так, щоб усі <PropertyGroup>розділи, які визначають ваші конфігурації збірки, були сусідні один з одним. (Щоб відредагувати .wixprojв VS2013 правою кнопкою миші на проект у Провіднику рішень, Розвантажити проект, ще раз клацніть правою кнопкою миші-> Редагувати свій проект.wixproj. Перезавантажте після редагування файлу.)

Це сталося зі мною, оскільки я перемістив наступний рядок близько до початку файлу .csproj:

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

Його потрібно розмістити після PropertyGroups, які визначають вашу Конфігурацію | Платформу.

Помилка, показана у візуальній студії для проекту (Скажімо, A), не має проблем. Коли я подивився на вихідне вікно для рядка збирання за кожним проектом, я побачив, що він скаржиться на інший проект (B), який був позначений як збірка в проекті А. Проект B доданий у рішення. Але це не було зазначено в проекті А як посилання на проект, а як посилання на збірку з іншого місця. Це місце містить збірку, складену для Platform AnyCpu. Потім я видалив посилання на збірку з проекту A і додав проект B в якості посилання. Він почав складати. Не знаю, хоч як це виправлення працювало

Я зіткнувся з тією ж помилкою, але проблема виявилася через те, що я створив нову конфігурацію в своєму рішенні, яка не існувала в посилальних збірках з іншого рішення.

Це можна вирішити, відкривши відповідне рішення та додавши до нього нову конфігурацію.

Ця публікація дала мені ідею перевірити посилання, після чого я вже підтвердив, що всі проекти в рамках мого рішення мають правильну конфігурацію:

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

мала цю проблему як вихід з Azure DevOps після встановлення .csproj замість .sln у конвеєрі побудови.

Для мене рішення: відредагуйте .csproj проекту, який стосується, та скопіюйте ціле

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

Вузол, вставити його, а потім змінити перший рядок так:

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

Причина в тому, що в моєму випадку помилка сказала

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

Чому Azure хоче використовувати "будь-який процесор" замість "AnyCpu" за замовчуванням, для мене є загадкою, але цей хак працює.

У мене була така ж помилка, тому я подивився на налаштування проекту, і там у розділі «Збірка» є варіант «Збірка вихідного шляху». І значення було порожнім. Тому я заповнив значення "bin \", помилка зникла. Це вирішило мою проблему.

У мене є:

1. Клацніть правою кнопкою миші на проект з проблемою -> Вивантажити проект
2. Клацніть правою кнопкою миші на проект і виберіть Правка * .csproj

3. Скопіюйте та вставте конфігурацію з існуючої конфігурації, яка працює з певною назвою та платформою націлювання (я мав 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. Клацніть правою кнопкою миші проект -> Перезавантажити проект
5. Побудувати проект / рішення

Якщо ви отримуєте цю помилку лише тоді, коли ви намагаєтеся скомпілювати ваш проект із командної лінії за допомогою MSBuild (як у моєму випадку), тоді рішення полягає в тому, щоб передати вихідний шлях вручну до MSBuild з таким аргументом /p:OutputPath=MyFolder.

Ще одна шалена можливість: Якщо ви дотримуєтесь простого режиму управління джерелами, щоб поставити Branch \ Main, Main і Release поруч один з одним, і ви якимось чином закінчите додавати існуючий проект від Main замість Branch \ Main (якщо припустимо, що ваше робоче рішення - це Відділення \ Головна), ви можете побачити цю помилку.

Рішення просте: посилайтеся на правильний проект!

Я зіткнувся з цією проблемою, коли додав проект до рішення, а потім посилався на його ще на один проект у тому ж рішенні - отримав жовтий значок попередження над посиланням, помітив, що шлях порожній.

Рішення було подібним до запропонованого @Amzath, мої проекти складалися з різних цільових рамок, наприклад. .NET 4.0 проти 4.5.

У моєму випадку вбудовану адресу мого додатка було встановлено на інший комп'ютер, який було вимкнено, тому я увімкнув його та перезапустив VS та вирішив проблему.

Інша причина: ви додаєте посилання на проект від проекту A до проекту B у рішення X. Однак рішення Y, яке вже містить проект A, тепер порушено, поки ви також не додасте проект B до рішення Y.

У мене була така ж проблема після того, як я додав нові конфігурації та видалив конфігурації "налагодження" та "випуск". У моєму випадку я використовував файл cmd для запуску процесу збирання та публікації, але та сама помилка була викинута. Для мене рішення: У файлі csproj наступне:

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

встановлював Конфігурацію на "Налагодження", якщо я не вказав явного. Після зміни значення вузла з "налагодження" на мою власну конфігурацію, все працювало безперебійно. Сподіваюся, що це також допоможе тому, хто це читає :)

У мене була така ж проблема. Просто відредагуйте .wixproj, щоб усі <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... >елементи були поруч.

Це вирішило моє питання

Проект WiX, який я використовував, був жорстко налаштований у менеджері конфігурації для x64всіх. Створюючи проект власної дії для рішення, він дефолтував усе, що є x86у .csprojфайлі. Тому я розвантажив проект, відредагував його, змінивши все x86на x64, збережене, перезавантажене і мені було добре піти після цього.

Я не розумію, чому мені довелося це робити. Менеджер конфігурацій був створений як x64, але просто не встановив би у csprojфайл :(

Спробувавши всі інші пропозиції, розміщені тут, я виявив, що рішення для мене було видалити наступний розділ з .csprojфайлу:

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

Мабуть, ця послуга з оригінального проекту (недоступна на локальній машині) зупиняла весь процес збирання, хоча це не було важливо для компіляції.

Цю проблему я отримав після додавання нової платформи до свого проекту. У моєму випадку файл .csproj знаходився під контролем джерела Perforce і був доступним лише для читання. Я перевірив це, але VS не вловив зміни, поки я не перезапустив її.

У мене був подібний випуск проекту Xamarin. Це може бути рідкісний випадок, але у випадку, якщо у когось іншого виникне проблема. моя структура проекту була, як нижче

• Проект xamarin.Android мав посилання на проект xamarin.android.library.
• Я створив плагін, використовуючи деякий код проекту android.library.
• Тепер ось проблема. якщо ви додали довідку про проект або встановлення нута в проект бібліотеки xamarin.android. Ви отримаєте цю помилку. Розробники припускають, що код знаходився в проекті Android.Library, і я повинен посилатися на новий плагін цього проекту. НЕМАЄ!
• ви повинні додати посилання на головний проект Android. тому що плагін-> бібліотека-> головний вихід проекту не виробляється.