Свойство OutputPath не установлено для этого проекта

Ответ 1

Ошибка, отображаемая в визуальной студии для проекта (пусть говорят), не имеет проблем. Когда я смотрел окно вывода для построения строки за строкой для каждого проекта, я увидел, что он жалуется на другой проект (B), который упоминался как сборка в проекте A. Проект B добавлен в решение. Но он не упоминался в проекте A как ссылка на проект вместо ссылки на сборку из другого места. Это место содержит сборку, которая скомпилирована для платформы AnyCpu. Затем я удалил ссылку на сборку из проекта A и добавил проект B в качестве ссылки. Он начал компилировать. Не знаю, как это исправить.

Ответ 2

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

Оказалось, что при добавлении конфигурации "Производство" для всего решения (и каждого проекта) элемент OutputPath не был добавлен в файлы .csproj.

Чтобы это исправить, я перешел на вкладку "Сборка" свойств проекта, изменил OutputPath с \bin\Production\ на \bin\Production (удаленный трейлинг \) и сохранил изменения. Это принудительно создало элемент OutputPath в файле .csproj, и проект был успешно собран.

Это звучит как глюк для меня.

Ответ 3

Вы можете увидеть эту ошибку в VS 2008, если у вас есть проект в вашем решении, который ссылается на сборку, которая не может быть найдена. Это может произойти, если сборка происходит из другого проекта, который не является частью вашего решения, но должен быть. В этом случае простое добавление правильного проекта к решению решит его.

Проверьте раздел "Ссылки" каждого проекта в своем решении. Если у кого-то из них есть ссылка с красным x рядом с ним, тогда вы нашли свою проблему. Эта ссылка на сборку не найдена решением.

Сообщение об ошибке немного запутанно, но я видел это много раз.

Ответ 4

Если вы используете WiX, посмотрите на это (есть ошибка) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

Иногда новые конфигурации сборки добавляются в файл .wixproj дальше по файлу, то есть отделяются от своих конфигураций конфигураций sibling другими несвязанными XML-элементами.

Просто отредактируйте файл .wixproj, чтобы все разделы <PropertyGroup>, которые определяют ваши конфигурации сборки, смежны друг с другом. (Чтобы отредактировать .wixproj в VS2013, щелкните правой кнопкой мыши по проекту в обозревателе решений, отпустите проект, щелкните правой кнопкой мыши еще раз → Edit YourProject.wixproj. Перезагрузите после редактирования файла.)

Ответ 5

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

Это можно решить, открыв соответствующее решение и добавив к нему новую конфигурацию.

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

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

Ответ 6

Это случилось со мной, потому что я переместил следующую строку ближе к началу файла .csproj:

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

Он должен быть размещен после PropertyGroups, которые определяют вашу конфигурацию | Платформа.

Ответ 7

У меня была такая же ошибка, поэтому я просмотрел параметры проекта, и там в разделе "Сборка" есть опция "Создать выходной путь". И значение было пустым. Таким образом, я заполнил значение "bin", ошибка исчезла. Он решил мою проблему.

Ответ 8

Если вы получаете эту ошибку только при попытке скомпилировать свой проект из командной строки с использованием MSBuild (как в моем случае), тогда решение состоит в том, чтобы вручную передать выходной путь в MSBuild с аргументом вроде /p:OutputPath=MyFolder.

Ответ 9

Еще одна сумасшедшая возможность: Если вы следуете простому механизму управления источниками размещения Branch\Main, Main и Release рядом друг с другом, и вы каким-то образом добавляете существующий проект из Main вместо Branch\Main (при условии, что ваше рабочее решение - Branch\Main), вы может видеть эту ошибку.

Решение прост: обратитесь к правильному проекту!

Ответ 10

Я столкнулся с этой проблемой при добавлении проекта в решение, а затем ссылался на него из другого проекта в том же решении - получил желтый значок предупреждения по ссылке, заметил, что путь пуст.

Решение было похоже на то, что предложил @Amzath, мои проекты составлялись с использованием разных целевых платформ, например..NET 4.0 vs 4.5.

Ответ 11

В моем случае встроенный адрес моего приложения был настроен на другой компьютер, который был выключен, поэтому я включил его и перезапустил VS и устранил проблему.

Ответ 12

У меня была такая же проблема после добавления новых конфигураций и удаления конфигураций "debug" и "release". В моем случае я использовал cmd файл для запуска процесса сборки и публикации, но эта же ошибка была брошена. Решение для меня: В файле csproj следующее:

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

устанавливала конфигурацию на "Debug", если я не указал явный. После изменения значения node от "debug" до моей пользовательской конфигурации все это работало гладко. Надеюсь, это также поможет тому, кто читает это:)

Ответ 13

Я имею:

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. Перестроить проект/решение

Ответ 14

Другая причина: вы добавляете ссылку на проект из проекта A в проект B в решении X. Однако решение Y, которое уже содержит проект A, теперь разбито, пока вы не добавите проект B в решение Y.

Ответ 15

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

Это решило мою проблему

Ответ 16

Проект WiX, который я использовал, был жестко установлен в менеджере конфигурации для x64 по всей доске. При создании проекта Custom Action для решения он по умолчанию задал значение x86 в файле .csproj. Поэтому я выгрузил проект, отредактировал его, изменив все x86 на x64, сохраненный, перезагруженный, и было хорошо после этого.

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

Ответ 17

Перепробовав все остальные предложения, опубликованные здесь, я обнаружил, что решение для меня .csproj чтобы удалить следующий раздел из файла .csproj:

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

По-видимому, этот сервис из исходного проекта (недоступный на локальной машине) останавливал весь процесс сборки, хотя он не был необходим для компиляции.

Ответ 18

возникла эта проблема в качестве выходных данных DevOps Azure после настройки для сборки .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" по умолчанию, для меня загадка, но этот хак работает.

Ответ 19

Я получил эту проблему после добавления новой платформы в мой проект. В моем случае файл .csproj находился под контролем исходного кода Perforce и был доступен только для чтения. Я проверил это, но VS не поймал изменение, пока я не перезапустил это.