10

У меня довольно большое решение (около 50 проектов, все C#), которые я создаю в VS 2012 (обновление 4). Я заметил, что после завершения полной перестройки из VS, непосредственно за которой следует сборка (удар F6), один проект перестраивается, хотя я ничего не трогал.Visual Studio (2012, 2015) восстанавливает проект, хотя ничего не изменилось

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

Настройка вывода MSBuild для диагностики и изучения выхода первой сборки вызова показывает это:

NuGet package restore started. 
Restoring NuGet packages for solution XXX. 
[... some boring lines on NuGet Package restore] 
All packages are already installed and there is nothing to restore. 
NuGet package restore finished. 
Project 'YYY' is not up to date. Last build was with unsaved files. 
------ Build started: Project: YYY, Configuration: Debug Any CPU ------ 
Build started 21-11-2013 21:20:54. 

Я особенно заинтригован сообщением, что Project 'YYY' is not up to date. Last build was with unsaved files. У меня нет несохраненных файлов. Интересно, что и Google, и Bing не дают ни единого удара при поиске этого сообщения.

Любые подсказки о том, что может вызвать это? Как я могу отладить эту часть процесса сборки? Я полагаю, что эта часть процесса сборки еще до вызова MsBuild (по крайней мере, новые функции восстановления пакета NuGet появляются до того, как MsBuild вызывается, я считаю, что MsBuild запускается из строки «Начал сборку».

+0

Имеет ли этот проект «особые» настройки в отношении других? Что это за проект? – Micha

+0

Просто обычная библиотека классов.Я проверил элементы с «Копировать в выходной каталог» - установка «Копировать всегда», ни одна не найдена (они могут испортиться). Я также удалил все * .suo файлы, чтобы быть уверенным. По какой-то причине VS продолжает думать, что в некотором файле есть несохраненные изменения, и я не могу понять, что. –

+0

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

ответ

2

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

3

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

Постройте свое решение и поиск выхода сборки панели для:

Done executing task "Copy" 

Чуть выше этой линии вы увидите линии, как это:

Did not copy from file 
Copying file from 

Вы увидите такие строки:

3> Copying file from "C:\Projects\test\Business.Core.Mto\bin\Debug\Business.Core.Mto.dll" to "bin\Debug\Business.Core.Mto.dll". (TaskId:68) 

Вы можете игнорировать копирование файлов, отличных от DLL

Перейдите в исходную строку, содержащую выполненную задачу «Копировать».

Теперь вы увидите строку:

3>Done building target "_CopyFilesMarkedCopyLocal" in project "Business.Core.Utils.csproj".: (TargetId:138) 

В Visual Studio откройте ссылки в рамках данного проекта. Удалите все ссылки и добавьте их обратно. Вы можете получить сообщение:

A reference to business.core.mto could not be added. Adding this project as a reference would cause a circular dependency 

Решение теперь может быть построено.

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

+0

Альтернативной причиной может быть то, что конфигурационный файл был настроен на «Копировать всегда» вместо «Копировать», если «Создать». –

+0

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