May
06
Proyecto “docker-compose” y configuraciones de VS2017

Trabajando en un nuevo proyecto de demostración llamado “CMCDSample”, con Visual Studio 2017, he encontrado una pequeña limiticación en los proyectos de “Docker” (“docker-compose”) en VS2017 y a continuación documento tanto la limitación como su solución.

Limitación de los proyectos “docker-compose” originales de VS2017

Cuando VS2017 compila (o ejecuta con F5) un proyecto “docker-compose” original de VS2017, comprueba si la configuración seleccionada es “Debug”, en cuyo caso busca un archivo, dentro del proyecto, llamado “docker-compose.vs.debug.yml” para utilizarlo en el proceso de compilación. Si la configuración actual no se llama literalmente “Debug”, entonces VS2017 asume que se trata de una “Release” e intenta utilzar (si existe) el archivo “docker-compose.vs.release.yml”.

El proyecto “CMCDSample”, demuestra cómo gestionar dos servidores Sitecore con roles diferentes (“Content Delivery” y “Content Manager”) dentro de un entorno de desarrollo. Esta solución de Visual Studio necesita una configuración para cada rol de servidor de Sitecore. Y a su vez, cada uno de estos roles necesita una versión de “Debug” y otra de “Release”. En definitiva, se necesitan las siguientes configuraciones:

  • DebugCD
  • DebugCM
  • ReleaseCD
  • ReleaseCM

El comportamiento de VS2017, descrito anteriormente entra en conflicto con la necesidad de tener varias configuraciones de “Debug” para los distintos roles de servidor Sitecore. La lógica aplicada al compilar hace que las configuraciones “DebugCD” y “DebugCM” se compilen como si fueran “Release”, desabilitando así toda la funcionalidad necesaria en un entorno de desarrollo para depurar el código.

Solución

Afortunadamente hay una solución sencilla que permite indicar para cada configuración personalilzada, si se debe aplicar la lógica de compilación de “Debug” o de “Release”.

Los pasos detallados a continuación describen cómo arreglarlo:

  1. Abrir la solución de VS2017 que contiene el proyecto “docker-compose” con configuraciones personalizadas.
  2. En el panel “Solution Explorer”, hacer clic con el botón derecho sobre el proyecto “docker-compose” y seleccionar “Unload Project”. El proyecto aparecerá en el panel “Solution Explorer” como “docker-compose (unavailable)”
  3. De nuevo, en el panel “Solution Explorer”, hacer clic con el botón derecho sobre el proyecto “docker-compose (unavailable)” y seleccionar “Edit docker-compose.dcproj”. Se abrirá el archivo “docker-compose.dcproj” en VS2017.
  4. Dentro del archivo “docker-compose.dcproj” buscar el elemento “<PropertyGroup Label=”Globals”> y a continuación de su etiqueta de cierre (</PropertyGroup>) añadir el siguiente elemento “PropertyGroup”:

    <PropertyGroup Label=”Custom”>
    <DockerDevelopmentMode Condition=” ‘$(Configuration)’ == ‘DebugCD‘ “>Fast</DockerDevelopmentMode>
    <DockerDevelopmentMode Condition=” ‘$(Configuration)’ == ‘DebugCM‘ “>Fast</DockerDevelopmentMode>
    <DockerDevelopmentMode Condition=” ‘$(Configuration)’ == ‘ReleaseCD‘ “>Regular</DockerDevelopmentMode>
    <DockerDevelopmentMode Condition=” ‘$(Configuration)’ == ‘ReleaseCM‘ “>Regular</DockerDevelopmentMode>
    </PropertyGroup>

  5. Nótese que hay un sub-elemento “DockerDevelopmentMode” por cada configuración de la solución. Los nombres utilizados en el atributo “Condition” tienen que conincidir con cada configuración. Debe haber un elemento “DockerDevelopmentMode” por cada configuración de la solución.
  6. Los valores de los nodos “DockerDevelopmentMode” indican cómo se debe tratar cada configuración:
    1. Fast: Debug
    2. Regular: Release
  7. Una vez modificado el archivo “docker-compose.dcproj” se debe guardar y cerrar en VS2017.
  8. Finalmente, en el panel “Solution Explorer”, hacer clic con el botón derecho sobre el proyecto “docker-compose (unavailable)” y seleccionar “Reload Project”.

Comentarios finales

Espero que esto ayude a alguien más. Si así lo fuera, por favor permite que lo sepa dejando un comentario.

Gracias!