Успешная сборка Visual Studio C # не создает сборку - PullRequest
3 голосов
/ 18 февраля 2009

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

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

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

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

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

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

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

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

Ответы [ 6 ]

4 голосов
/ 18 февраля 2009

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

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

1 голос
/ 18 февраля 2009

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

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

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

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

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

0 голосов
/ 04 сентября 2014

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

0 голосов
/ 10 марта 2010

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

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

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

0 голосов
/ 18 февраля 2009

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

0 голосов
/ 18 февраля 2009

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

...