Инкрементная поддержка сборки в проектах Biztalk 2009 и 2010 .btproj? - PullRequest
5 голосов
/ 14 апреля 2011

В погоне за улучшением времени инкрементной сборки я обнаружил, что файлы .btproj и, следовательно, все другие проекты, которые зависят от них, перестраиваются (частично) при каждой инкрементной сборке.Отслеживая это вплоть до BizTalkCommon.targets, я обнаружил, что он выполняет двухпроходную компиляцию сборки - но только первый проход учитывает уже созданные артефакты, тем самым нарушая добавочную часть цепочки зависимостей.Неприятную цель можно увидеть в BizTalkCommon.targets (строка 228):

<!-- Delete the assembly and rerun the build process -->
<Target Name="SecondPass"
        Condition="$(SecondBuild)!=true and $(TempAssemblyOnly)!=true">

    <Delete Files="@(IntermediateAssembly)" />
    <MSBuild Projects="$(MSBuildProjectFile)" Properties="SecondBuild=true"/>
</Target>

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

Кто-нибудь знает, есть ли исправление для файла .targets или есть еще одна веская причина, по которой инкрементные сборки не поддерживаются?

Ответы [ 2 ]

3 голосов
/ 26 октября 2011

Вы можете включить пошаговую компиляцию проекта MSBuild BizTalk с помощью пары очень простых изменений.По сути, вам необходимо переопределить две цели, которые определены в файле BizTalkCommon.targets.

Эти цели могут быть переопределены в ваших собственных файлах .btproj и не требуют изменения исходного файла .targets, поставляемого с BizTalk.

How To

Сначала создайте собственный файл .targets для размещения ваших настроек, например BizTalkCustom.targets:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\BizTalk\BizTalkC.targets" />

<!-- Rerun the build process (second pass) -->
<Target Name="SecondPass" Condition="$(SecondBuild)!=true and $(TempAssemblyOnly)!=true and @(XLang)!=''">
    <MSBuild Projects="$(MSBuildProjectFile)" Properties="SecondBuild=true" />
</Target>

<!-- Compile XLang/s orchestration -->
<Target
    Name="CompileODX"
    Condition="$(SecondBuild)==true"
    Inputs="@(XLang);$(MSBuildAllProjects);$(ClrTypesAssembly)"
    Outputs="$(BuildDone)">

  <!-- Delete previously generated C# files from XLang compilation -->
  <Delete Files="@(IntermediateAssembly)" />
  <Delete Files="@(CSharpOutputFromXLang)" />

  <XLangTask XLangItems="@(XLang)"
             ProjectReferences="@(ReferencePath)"
             WarningLevel="$(WarningLevel)"
             BpelCompliance="$(BpelCompliance)"
             DefineConstants="$(DefineConstants)"
             TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
             TempAssembly="$(ClrTypesAssembly)"
             OutputDirectory="$(XLangOutputPath)">
  </XLangTask>
</Target>

Затем заменитепоследний оператор Import в вашем файле .btproj:

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="$(MyCustomExtensions)\BizTalkCustom.targets" />

Как это работает

Проекты BizTalk Server необходимо каким-то образом компилировать в два этапа.Первый проход компилирует схемы, карты и конвейеры, тогда как второй проход компилирует оркестровки.

Вы заметите, что переопределенные цели очень очень похожи на исходные цели, определенные в BizTalkCommon.targets file.На самом деле я сделал два простых изменения:

  1. Первое изменение включает изменение цели SecondPass и добавление дополнительного теста в атрибут Condition.Этот тест полезен для предотвращения повторного прохождения, если ваш проект даже не имеет оркестровок.

  2. К сожалению, если ваш проект содержит оркестровки, исходная цель SecondPass удаляет промежуточные сборкиа затем приступить к составлению оркестровок.Тем не менее, цель CompileODX не должна запускаться, если все файлы уже обновлены.Следовательно, второе изменение включает перемещение задачи Delete из цели SecondPass в цель CompiledODX.

Это все, что нужно сделать.

1 голос
/ 23 апреля 2011

Это то, с чем моя команда столкнулась некоторое время назад, просто отказалась от настройки файлов сборки и вместо этого применила инфраструктуру развертывания BizTalk, расположенную здесь . BizTalk делает много «забавных» вещей на уровне VS, так как 2009 год был первой версией, BizTalk не использовал внешний процесс сборки. Но я не уверен, зачем нужен второй проход, кроме как с точки зрения дизайнера.

...