Предотвратить полное перестроение проектов BizTalk?

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

Является ли это известным недостатком BizTalk или его взаимодействия с MSBuild? Это известная ловушка, которую я могу исправить со своей стороны?

РЕДАКТИРОВАТЬ: после просмотра темы «возможный дубликат» я считаю, что этот вопрос похож, но отличается. Объяснение из потока подчеркивает механизм, с помощью которого MSBuild определяет необходимость перестроения, но MSBuild является широко используемой технологией во всех проектах в Visual Studio и может значительно отличаться в зависимости от типа проекта в зависимости от импорта конкретных целей этого типа проекта. Я отредактировал заголовок вопроса, чтобы отразить, что я хочу узнать, как предотвратить это для решений BizTalk, а не просто спрашивать, почему это происходит (хотя знать почему всегда полезно).


unit-testing biztalk vs-unit-testing-framework visual-studio-2012 biztalk-2013
person bwerks    schedule 10.03.2016    source источник
comment
Возможный дубликат Ненужные перестроения проекта при модульном тестировании в Visual Studio Это не просто решения для бизнеса.   -  person Dijkgraaf    schedule 10.03.2016
comment
Сначала я согласился с проблемой дублирования, но эта проблема, похоже, немного более специфична для проектов BizTalk.   -  person Dan Field    schedule 10.03.2016
comment
Связанный вопрос без принятого ответа сборки"> stackoverflow.com/questions/33870271/   -  person Dijkgraaf    schedule 16.03.2016

Ответы (3)


arrow_upward
3
arrow_downward

Итак, то, что вы видите, не является проблемой для BizTalk (потому что BizTalk идеален и прекрасен, и у него никогда не бывает проблем...:).

На самом деле это поведение Visual Studio. Следует отметить, что проекты BizTalk — это просто специализированные проекты c#.

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

person Johns-305    schedule 10.03.2016
comment
На самом деле я пробовал что-то подобное в прошлом, выгружая уже созданные проекты, но, к сожалению, VS жаловался на отсутствие ссылки. Я дам этому шанс, хотя! Я думаю, что это в конечном итоге укусит кого-то в моей организации, поскольку изменение этих настроек приведет к отложенным изменениям в файле .sln, но, возможно, при достаточно хорошем общении мы все еще можем извлечь из этого пользу. - person bwerks; 10.03.2016

arrow_upward
2
arrow_downward

Одним из возможных решений было бы ссылаться не на проекты, а на файлы DLL, которые являются результатом тех же - уже скомпилированных и построенных - проектов.

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

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

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

person Pieter Vandenheede    schedule 10.03.2016
comment
С практической точки зрения, даже при использовании ProjectReference я нахожу много ситуаций, когда VS кричит на меня о несоответствии dll/кодовых файлов, когда я отлаживаю модульный тест, поэтому я все равно уже привык заранее создавать код своего продукта перед тестированием. Это решение может быть отличным решением! - person bwerks; 10.03.2016

arrow_upward
2
arrow_downward

Я тоже это заметил. Включив диагностический вывод в MSBuild, оказалось, что файлы настроек проекта .user модифицируются после .pdb файлов. Я пробовал несколько способов решить эту проблему, включая изменение даты изменения в файле pdb, настройку файла .user только для чтения, удаление (переименование) файла .user и т. д.

К сожалению, задача сборки для BizTalk будет перезаписывать/воссоздавать/создавать новый файл .user после каждой сборки, и я не придумал способа убедить MSBuild, что он может просто игнорировать файл .user, создаваемый как новый. В связи с этим я бы согласился с одним из других предложений здесь.

Даже создание эксклюзивной блокировки файла, чтобы MSBuild не мог его обновить, вызывает перестроение, поскольку тогда MSBuild считает сборку грязной («Проект «Схемы» не обновлен. Проект грязный в MSBuild».)

person Dan Field    schedule 10.03.2016
comment
Отлично, это именно тот контекст, который я искал. Спасибо за понимание! - person bwerks; 10.03.2016
comment
Пытался удалить .user-файл в событиях до и после сборки, но он создает новый файл перед началом сборки, затем проверяет, не было ли что-то изменено после последней сборки, и обнаруживает, что .user-файл был создан после слов. .аккуратный. Я предполагаю, что требуется обновление шаблона проекта? - person JERKER; 14.02.2019