2013-08-14 3 views
1

Я работаю над системой сборки продукта, который содержит несколько сотен проектов C++ и C# в Visual Studio 2012. Я пытаюсь свести к минимуму количество ненужных перестроек, которое VS/MSBuild делает после обновления SVN (путем устранения множества небольших проблем, которые заставляют MSBuild думать, что проект нуждается в сборке, когда это действительно не так).Реконструкция проектов из-за необъяснимых недостающих вводов

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

Один из них - проект C++ с использованием CLR. Согласно Sysinternals Debug Viewer, по причине хочет восстановить после копирования является:

[4520] up to date is missing: 'C:\WINDOWS\ASSEMBLY\NATIVEIMAGES_V4.0.30319_64\SYSTEM\92AE81C9B2BA0AD6ED7B7450EE024DC9\SYSTEM.NI.DLL.AUX' 
[4520] up to date is missing: 'C:\WINDOWS\ASSEMBLY\NATIVEIMAGES_V4.0.30319_64\SYSTEM.XML\6EDF8B6D912547891F6EA5F12307C003\SYSTEM.XML.NI.DLL.AUX' 

Это означает для меня, что проект ищет вещи в GAC в качестве вклада в сборку. Этот проект включает System.Xml в качестве ссылки на сборку, но он правильно указан (из каталога Framework). Поскольку две машины сборки имеют один и тот же образ, все находится в одном и том же месте; конечно же, ПКК будут разными, но сборка не должна вообще смотреть на ПКК. Я не вижу ничего в проекте, чтобы указать, почему он будет искать эту сборку в GAC. Странная вещь, даже машина, которая изначально создала сборку, не имеет System.Xml 4.0 в GAC, из того, что я могу сказать. После того, как этот проект восстанавливается один раз на новой машине, все в порядке ... ничего не меняется в GAC, а последующие инкрементные сборки не беспокоят проект.

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

Редактировать: После некоторого дальнейшего расследования я нашел некоторые подсказки. Файл xdcmake.read.1.tlog в каталоге сборки ссылается на те файлы, о которых говорилось выше. По какой-то причине grep Cygwin не находит текст внутри этого файла, поэтому мой первоначальный поиск не нашел его. Во всяком случае, я использовал Process Monitor, чтобы посмотреть, какие файлы Visual Studio были доступны непосредственно перед запуском сборки, и это было одним из них.

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

ответ

1

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

Файл xdcmake.read.1.tlog в каталоге сборки ссылается на те файлы, о которых говорилось выше. xdcmake предназначен для создания файлов xml документации для вашей сборки. Должна быть некоторая некорректная конфигурация в некоторых сборках инфраструктуры .Net (в приведенном выше случае System.XML), которые заставляют xdcmake ссылаться на них в GAC вместо их правильного расположения.

Решение является удалением ссылок на сборки GAC во всех файлах xdcmake.read перед инкрементной сборкой.