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

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

Вот раздел группы свойств для этого файла .csproj

 true bin\x86\Debug\ DEBUG;TRACE 285212672 4096 full x86 prompt 

Может ли кто-нибудь пролить свет на это?

ПРИМЕЧАНИЕ. Когда я скомпилировал этот отладочный и любой CPU, он сработал.

ОБНОВЛЕНО: Ошибка 1 Свойство OutputPath для этого проекта не установлено. Убедитесь, что вы указали правильную комбинацию «Конфигурация / Платформа». Configuration = ‘Debug’ Platform = ‘x86’

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Debug< /Configuration> 

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

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

   

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

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

У меня была та же проблема. Просто отредактируйте файл .wixproj, чтобы все элементы

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

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

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

     

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

  • #define NOMINMAX с использованием std :: min / max
  • Отображение иерархии #include для файла C ++ в Visual Studio
  • Как перейти от проекта Visual Studio 2012 к Visual Studio 2008
  • Пользовательский контроль и форма Windows
  • Как заставить Visual Studio восстанавливать файлы .designer для файлов aspx / ascx?
  • Отключение автоматического форматирования в Visual Studio
  • В чем разница между параметрами компилятора / Ox и / O2?
  • Ограничения на установку расширений или надстроек в Visual Studio 2010 Express
  • Почему возникла связанная с сетью или конкретная ошибка экземпляра при установлении соединения с SQL Server?
  • Отладка / загрузка Visual Studio очень медленно
  • Проект строит, но не может публиковать
  • Давайте будем гением компьютера.