Успешная сборка Visual Studio C # не создает сборку

Я использую Visual Studio 2005, .NET 2.0

Я еще не совсем уверен, при каких обстоятельствах это происходит, но вот сценарий: у меня есть решение с такой структурой проекта: проект библиотеки Foo, проект библиотеки Bar, который ссылается на Foo, и проект библиотеки Quux, который ссылается на Foo и Бар.

Сбой компиляции с сообщением об ошибке «Файл метаданных 'Foo.dll' не может быть найден» из Bar, и «Не удалось найти файл метаданных 'Foo.dll'» и «Не удалось найти файл метаданных 'Bar.dll'» от Quux.

Заглянув в свой целевой каталог (у меня есть объединенный целевой каталог для всех трех проектов), он пуст, поэтому проект вообще не компилируется. Теперь я могу получить этот Bar, а Quux выйдет из строя, если Foo не выведет данные. Проблема в том, почему Foo молча терпит неудачу? В этом нет ошибки, и просто создание Foo вместо всего решения работает нормально.

"Забавно" то, что после простого нажатия кнопки сборки снова появляется файл Foo.dll, Bar больше не жалуется, но также не создает выходной файл, а Quux жалуется на отсутствие Bar.dll. При повторном нажатии на кнопку появляется Bar.dll, ошибок больше нет, но нет Quux.dll. Только после повторного нажатия кнопки появляется Quux.dll, снова без ошибок.

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

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

Я в полном тупике. Кто-нибудь знает выход из этого бардака?


.net c# build-process visual-studio-2005
person Community    schedule 18.02.2009    source источник
comment
Я по-прежнему рекомендую вам получить Visual Studio 2008 и нацелиться на разработку 2.0, несмотря на пресловутую позицию людей по отношению к моему ответу. В VS2005 есть ошибки, в VS2008 их нет. Вполне вероятно, что простая повторная установка решит эту проблему.   -  person John Leidegren    schedule 18.02.2009

Ответы (7)


arrow_upward
4
arrow_downward

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

Не бойтесь потерять какие-либо библиотеки DLL, они будут скопированы в каждый каталог bin, где они необходимы.

person Fabian Vilers    schedule 18.02.2009

arrow_upward
1
arrow_downward

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

Когда вы настроите три проекта для работы таким образом, вы обнаружите, что компилируете каждый проект в соответствующую папку bin и в комбинированный целевой каталог. Если вы решите работать с этим, вам следует сделать второе: настроить для каждого проекта в своем решении путь ссылки, указывающий на объединенный целевой каталог. Порядок компиляции все еще должен существовать.

Таким образом, каждая DLL проекта будет находиться в объединенном целевом каталоге при каждой компиляции.

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

Надеюсь это поможет

person El Padrino    schedule 18.02.2009

arrow_upward
0
arrow_downward

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

person sharptooth    schedule 18.02.2009
comment
Я уже писал: все зависимости проекта настроены правильно, порядок сборки решения говорит именно то, что нужно. - person ; 18.02.2009
comment
Неужели они строят именно в таком порядке (хотя бы попробовать)? - person sharptooth; 18.02.2009
comment
да. Фу, потом Бар, потом Куукс. Foo говорит, что он скомпилирован, Bar и Quux не работают из-за отсутствия Foo. И в целевом каталоге нет Foo. - person ; 18.02.2009
comment
Затем я предполагаю, что есть какой-то шаг, который удаляет сборку. Старайтесь использовать отдельные каталоги для результатов каждого проекта. Добавьте настраиваемый шаг сборки, чтобы скопировать сборку в необходимую общую папку, чтобы все они были в одном месте, если вам это нужно. - person sharptooth; 18.02.2009
comment
Может быть, вы используете событие после сборки в любом из проектов, чтобы скопировать библиотеки DLL в ваш объединенный целевой каталог? - person El Padrino; 18.02.2009
comment
Если это окажется действительно странным, может помочь Process Monitor (technet.microsoft.com/ en-us / sysinternals / bb896645.aspx). - person sharptooth; 18.02.2009

arrow_upward
0
arrow_downward

Проверьте порядок сборки, чтобы все выглядело правильно. Попробуйте запустить чистое решение и построить заново. Когда это произойдет?

person Peter    schedule 18.02.2009

arrow_upward
0
arrow_downward

Перетащите файл проекта в блокнот, найдите его с помощью тега «Импорт» и замените этот тег этим

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

Это должно работать

person Ramana    schedule 10.03.2010

arrow_upward
0
arrow_downward

По неизвестным причинам это случилось со мной с Visual Studio 2013 посреди утренней работы. Одна сборка обновляла dll, следующая - нет, хотя сборка, казалось, прошла гладко. Я наконец решил это, удалив существующую dll. При отсутствии ранее существовавшей dll сборка должна была предоставить новую.

person Leonard Wilson    schedule 04.09.2014

arrow_upward
0
arrow_downward

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

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

Я сделал как обычно

  • очистить / восстановить
  • очистить / перестроить каждый проект по порядку
  • проверьте зависимости проекта и порядок сборки
  • перезапустить vis studio (знаю, что это 2020 год, и мне все равно иногда приходится перезапускать vs)

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

  1. удалены все ссылки на другие проекты
  2. закомментировал весь код, который от них зависел.

у меня остался в значительной степени main (), который возвращал 0, это скомпилированные и созданные файлы

  1. один за другим я добавлял ссылки, пока все не было там.
  2. раскомментировал код.

в конце этого упражнения все заработало.

Не могу сказать, что изменилось. Думал, что предлагаю это как метод устранения неполадок.

person greg    schedule 09.12.2020