Soporte de compilación incremental en los proyectos Biztalk 2009 y 2010 .btproj?

Question

Mientras buscaba mejoras en el tiempo de compilación incremental, encontré que los archivos .btproj y, por lo tanto, todos los demás proyectos que dependen de estos se reconstruyen (parcialmente) en cada compilación incremental. Siguiendo este camino hasta BizTalkCommon.targets, encontré que realiza una compilación de 2 pasos del ensamblado, pero solo el primer paso respeta los artefactos ya construidos, rompiendo así la parte incremental de la cadena de dependencia. El objetivo infractor puede verse en BizTalkCommon.targets (línea 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> 

Soy consciente de que hay una razón para la construcción de 2 pasos, pero simplemente no puedo creer que no sería posible especificar in- apropiado y resultados para que el destino maneje las compilaciones incrementales correctamente.

¿Alguien sabe si hay un parche para el archivo .targets, o si hay otra buena razón por la que las compilaciones incrementales no son compatibles?

Answer 1

Puede habilitar la compilación incremental del proyecto MSBuild BizTalk con un par de cambios muy simples. Básicamente, debe anular dos destinos definidos en el archivo BizTalkCommon.targets.

Esos objetivos se pueden sobrescribir en sus propios archivos .btproj y no es necesario modificar el archivo original de .targets que se envía con BizTalk.

Cómo

En primer lugar crear su propio archivo de .targets para alojar sus personalizaciones, por ejemplo 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> 

A continuación, sustituir la última Import declaración en su archivo .btproj:

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

¿Cómo funciona?

Los proyectos de BizTalk Server deben compilarse de alguna manera en dos pasos. El primer pase compila esquemas, mapas y tuberías, mientras que el segundo paso compila orquestaciones.

Notarás que los objetivos sobreescritos son muy muy similares a los originales, definidos dentro del BizTalkCommon.targets file. De hecho, he hecho dos cambios simples:

1. El primer cambio implica la modificación del SecondPass destino y la adición de una prueba adicional en el atributo Condition. Esta prueba es útil para evitar que ocurra el segundo pase si su proyecto ni siquiera tiene orquestaciones.

2. Desafortunadamente, si su proyecto contiene orquestaciones, el objetivo original SecondPass borra los ensamblajes intermedios y luego procede a compilar las orquestaciones. Sin embargo, el objetivo CompileODX no necesita ejecutarse si todos los archivos están actualizados.Por lo tanto, el segundo cambio implica mover la Tarea Delete del SecondPass Objetivo al CompiledODX Objetivo.

Eso es todo.

Answer 2

Esto es algo que mi equipo encontró hace un tiempo atrás y simplemente dejó de personalizar los archivos de compilación y se fue con el marco de implementación de BizTalk, ubicado here. BizTalk hace muchas cosas "divertidas" desde un nivel de VS, ya que 2009 fue la primera versión en que BizTalk no utilizó un proceso de compilación externo. Pero no estoy seguro de por qué se necesita el segundo pase, excepto tal vez desde la perspectiva del diseñador.