Не разрешать проектам BizTalk использовать полную перестройку?

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Лучшее решение, которое я делаю все время, заключается в том, чтобы снять флажки Build and Deploy для проектов, с которыми я не активно работаю в Configuration Solution. Если Project не установлен для Build, он не будет создан, даже если вы выберете Rebuild Solution.

Answer 3

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

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

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