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


120

Когда я пытаюсь скомпилировать свой проект из режима отладки 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 не задано для этого проекта. Убедитесь, что вы указали допустимую комбинацию конфигурации / платформы. Конфигурация = 'Отладка' Платформа = 'x86'


Хорошо, а какую конфигурацию и платформу вы используете? Debug + x86 или еще что?
Ondrej Tucny

Да VS Configuration Manager Я выбираю debug + x86
Amzath

@DmitryShkuropatsky обновил сообщение об ошибке
Амзат

1
Выглядит правильно. Есть ли в решении другой проект, который может вызвать ошибку?
Дмитрий Шкуропатский

@DmitryShkuropatsky, вы правы, проблема была в другом проекте. Но VS пожаловался на компилируемый проект
Амзат

Ответы:


214

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

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

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

Для меня это похоже на сбой.


7
Хорошая уловка этой ртутной ошибки. Никогда бы не подумал, что одна косая черта может иметь такое большое значение. Получите значок "Хороший ответ".
ouflak

8
В моем случае при создании файла proj проблема заключалась в разнице между any cpuи anycpu, но ваш пост помог мне это увидеть.
Джошуа Дрейк

2
Спасибо, Роман, ты спас мне день ... если бы я мог 100 раз проголосовать за твой ответ! :)
Мартин

2
Только что столкнулся с этим в VS 2017 v15.6.6, бекон сохранен, спасибо!
Angrist

1
@Joshua Drake, это важная проблема при использовании VSTS. Онлайн-студия Visual Studio использует «любой процессор», а локальная визуальная студия - «anycpy». Важно для скриптов сборки.
FrankyHollywood

28

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

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

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


2
В моем случае это было «желтое предупреждение»
AXMIM

26

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

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

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


1
спасибо, это исправило это для меня. Чем больше конфигураций я добавил в проект, тем больше у меня было странного поведения. Как только я очистил файл проекта, все заработало. (Впервые об этой ошибке сообщили в 2012 году?
Отлично

Спасибо, это исправило это и для меня
PeterD

15

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

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

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


11

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


15
Деффо попробуйте использовать \ p: Platform = "AnyCPU" вместо \ p: Platform = "Any CPU". Это сработало у меня! Смотрел на это целую вечность!
Ли Энглстон

AnyCPU (без пробела) также работал у меня. Спасибо, Ли.
Виллем 05

1
Я столкнулся с ошибкой при запуске процесса сборки в TFS 2017 после того, как я изменил «Путь к решению или packages.config» с .sln на .vbproj. У меня тоже сработало изменение BuildPlatform на AnyCPU. См. Примечание в разделе «Платформа» здесь: docs.microsoft.com/en-us/vsts/build-release/tasks/build/…
Mr.Zzyzzx 01

2
В моем случае при запуске сборки из TFS "any cpu"значение по умолчанию для BuildPlatform. Переход к "AnyCPU"решенной проблеме.
XouDo

Это 2020 год - AnyCPU vs Any CPU по-прежнему создает проблемы. Я использую VS2019 и до сих пор использую это в новых проектах. MS, почему вы наказываете сообщество разработчиков?
Кристиан

9

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

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

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

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


7

эта проблема возникла на выходе из Azure DevOps после настройки сборки .csproj вместо .sln в конвейере сборки.

Решение для меня: отредактируйте .csproj затронутого проекта, затем скопируйте весь свой

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

Node, вставьте его и измените первую строку следующим образом:

    <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 хочет использовать «any cpu» вместо «AnyCpu» по умолчанию, для меня загадка, но этот прием работает.


Следуя вашей идее, я обнаружил, что в моем случае мне не нужно было вносить изменения в проект, но вместо этого на этапе сборки Visual Studio в DevOps я настроил поле Confguration для использования переменной со значением AnyCpu.
donatasj87

@ donatasj87, не могли бы вы опубликовать полное значение этого поля?
Джей

1
Полное значение точно такое же, это также должно работать в сборке TFS. Ему просто нужно соответствовать значению, установленному в вашем файле .csproj. Вы можете увидеть его в этой картине: pasteboard.co/JbdvBT5.png
donatasj87

4

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


3

У меня есть:

  1. Щелкните правой кнопкой мыши проект с проблемой -> Выгрузить проект
  2. Щелкните проект правой кнопкой мыши и выберите Edit * .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. Восстановить проект / решение

3

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


2

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

Решение простое: укажите правильный проект!


2

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

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


2

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


2

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


2

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

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

устанавливал для Конфигурации значение «Отладка», если я не указывал явное значение. После изменения значения узла с «отладки» на мою настраиваемую конфигурацию все работало гладко. Надеюсь, это также поможет тем, кто это читает :)


Подробности этого решения упомянуты в этом сообщении на форуме. social.msdn.microsoft.com/Forums/vstudio/en-US/…
Санни Тамби,

2

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

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


1

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

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


0

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

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

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


0

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


0

У меня была аналогичная проблема в проекте Xamarin. Это может быть редкий случай, но на тот случай, если проблема возникла у кого-то еще. моя структура проекта была такой, как показано ниже

  • На проект xamarin.Android была ссылка из проекта xamarin.android.library.
  • Я создал плагин, используя код из проекта android.library.
  • Теперь вот в чем проблема. если вы добавляете ссылку на проект или установку nuget в проект библиотеки xamarin.android. Вы получите эту ошибку. Разработчики предполагают, что код находится внутри проекта Android.Library, и я должен указать новый плагин в этом проекте. НЕТ!
  • вы должны добавить ссылку на основной проект Android. потому что плагин-> библиотека-> основной вывод проекта не создается.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.