2011-04-14 3 views
5

점진적 빌드 시간 개선을 추적하면서 .btproj 파일을 발견 했으므로 이에 의존하는 다른 모든 프로젝트가 각 증분 빌드에서 (부분적으로) 다시 빌드됩니다. 이것을 BizTalkCommon.targets 에까지 추적하면서 어셈블리의 2 단계 컴파일을 수행했지만 첫 번째 단계에서만 이미 작성된 아티팩트를 존중하므로 종속성 체인의 증분 부분이 깨졌습니다. 문제가되는 대상이 BizTalkCommon.targets (라인 228)에서 볼 수있다 :Biztalk 2009 및 2010 .btproj 프로젝트의 증분 빌드 지원?

<!-- 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 파일에 대한 패치가 있는지 또는 증분 빌드가 지원되지 않는 다른 좋은 이유가 있는지 아는 사람 있습니까?

답변

3

몇 가지 매우 간단한 변경 사항으로 MSBuild BizTalk 프로젝트를 증분 컴파일 할 수 있습니다. 기본적으로 BizTalkCommon.targets 파일에 정의 된 두 개의 대상을 재정의해야합니다.

이러한 대상은 사용자의 .btproj 파일에서 재정의 될 수 있으며 BizTalk와 함께 제공되는 원래 .targets 파일을 수정할 필요가 없습니다.

예를 BizTalkCustom.targets를 들어, 사용자 정의를 호스트하기 위해 당신이 .targets에게 파일을 소유

먼저 만드는 방법 : 당신의 .btproj 파일의 마지막 Import 문을 대체, 그리고

<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 Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> 
    <Import Project="$(MyCustomExtensions)\BizTalkCustom.targets" /> 

어떻게 작동합니까?

BizTalk Server 프로젝트는 어떻게 든 두 단계로 컴파일해야합니다. 첫 번째 패스는 스키마, 맵 및 파이프 라인을 컴파일하는 반면 두 번째 패스는 오케스트레이션을 컴파일합니다.

오버라이드 된 타겟이 BizTalkCommon.targets file 내부에 정의 된 원래의 타겟과 매우 매우 비슷하다는 것을 알 수 있습니다.

  1. 첫 번째 변화는 SecondPass 목표를 수정하고 Condition 속성에 추가 테스트를 추가 포함 : 사실, 나는 두 가지 간단한 변경했습니다. 이 테스트는 프로젝트에 오케스트레이션이없는 경우에도 두 번째 패스가 발생하지 않도록하는 데 유용합니다.

  2. 불행하게도 프로젝트에 오케스트레이션이 포함되어 있으면 원래 SecondPass 대상이 중간 어셈블리를 삭제 한 다음 오케스트레이션을 컴파일합니다. 그러나 모든 파일이 이미 최신 상태 인 경우 CompileODX 대상을 실행할 필요가 없습니다.따라서 두 번째 변경은 작업을 SecondPass 대상에서 CompiledODX 대상으로 이동하는 것과 관련이 있습니다.

그게 전부입니다.

+0

BizTalk 2010에서이 기능을 사용해 보셨습니까? –

+0

은 BizTalk Server 2010에서 작동합니다. 그러나 BizTalk Server 2010 R2를 사용해 볼 기회는 없었습니다. –

+0

시도해보십시오. 실제로 작동합니다. 빌드 시간이 크게 줄어 듭니다. 감사! –

1

이것은 우리 팀이 잠시 후에 만났고 단순히 빌드 파일 사용자 지정을 중단하고 대신 here에 위치한 BizTalk 배포 프레임 워크를 사용했습니다. 2009 년이 BizTalk가 외부 빌드 프로세스를 사용하지 않은 첫 번째 버전 이었기 때문에 BizTalk는 VS 수준에서 많은 "우스운"일을합니다. 하지만 두 번째 패스가 필요한 이유는 잘 모르겠다. 아마도 디자이너의 관점을 제외하고.

+0

BizTalk 배포 프레임 워크는 유망 해 보이지만 실제로 볼 수있는 한 증분 빌드를위한 빌드 시간을 실제로는 도움이되지 않습니까? – RasmusKL

+1

그것은 특별히 문제를 해결하지는 않지만 조금 더 가까이 갈 수 있도록 확장 할 수있는 몇 가지 고리가 있습니다. BizTalk 빌드는 일종의 블랙 박스이며 지나치게 혼란 스러울 경우 확실히 문제가됩니다. –

관련 문제