5

インクリメンタル ビルド時間の改善を追跡しているときに、.btproj ファイルと、これらに依存する他のすべてのプロジェクトが、各インクリメンタル ビルドで (部分的に) 再ビルドされることがわかりました。これを BizTalkCommon.targets まで追跡すると、アセンブリの 2 パス コンパイルが実行されることがわかりましたが、最初のパスのみが既に構築されたアーティファクトを尊重するため、依存関係チェーンの増分部分が壊れます。問題のあるターゲットは、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>

2 パス ビルドには理由があることは理解していますが、ターゲットがインクリメンタル ビルドを正しく処理するための適切な入出力を指定できないとは信じられません。

.targets ファイルのパッチがあるかどうか、または増分ビルドがサポートされていない別の正当な理由があるかどうか、誰かが知っていますか?

4

2 に答える 2

3

いくつかの非常に簡単な変更を行うだけで、MSBuild BizTalk プロジェクトのインクリメンタル コンパイルを有効にすることができます。基本的に、ファイルで定義されている 2 つのターゲットをオーバーライドする必要がありBizTalkCommon.targetsます。

これらのターゲットは、独自の .btproj ファイルでオーバーライドでき、BizTalk に同梱されている元の .targets ファイルを変更する必要はありません。

方法

まず、独自の .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>

次に、.btproj ファイルの最後のImportステートメントを置き換えます。

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

それはどのように機能しますか

BizTalk Server プロジェクトは、何らかの形で 2 つのパスでコンパイルする必要があります。最初のパスはスキーマ、マップ、およびパイプラインをコンパイルし、2 番目のパスはオーケストレーションをコンパイルします。

オーバーライドされたターゲットは、BizTalkCommon.targets file. 実際、私は 2 つの簡単な変更を加えました。

  1. 最初の変更には、SecondPassTarget の変更と属性へのテストの追加が含まれConditionます。このテストは、プロジェクトにオーケストレーションさえない場合に、2 番目のパスが発生するのを防ぐのに役立ちます。

  2. 残念ながら、プロジェクトにオーケストレーションが含まれている場合、元のSecondPassターゲットは中間アセンブリを削除してから、オーケストレーションのコンパイルに進みます。ただし、CompileODXすべてのファイルがすでに最新の状態である場合、ターゲットを実行する必要はありません。したがって、2 番目の変更には、DeleteタスクをSecondPassターゲットからターゲットに移動することが含まれCompiledODXます。

それだけです。

于 2011-10-26T10:41:50.397 に答える
1

これは私のチームがしばらく前に遭遇したことであり、ビルド ファイルのカスタマイズをやめて、代わりにここにある BizTalk 展開フレームワークを使用しました。2009 年が BizTalk が外部ビルド プロセスを使用しなかった最初のバージョンだったので、BizTalk は VS レベルから多くの "面白い" ことを行います。しかし、デザイナーの観点以外では、2 番目のパスが必要な理由はわかりません。

于 2011-04-23T12:45:31.237 に答える