Una de las cosas que normalmente pasa en los proyectos es que los settings de los diferentes artefactos en el binding es diferente. Para experimentar con esto, decidí usar el EnvironmentSettingManager que se aplica dentro del deploymentframework.
La primera cosa que ví es que a pesar de que la documentación expresa que al cerrar la planila se actualizan los archivos (por una macro), esto no sucede, pero es fácilmente subsanable usando el utilitario EnvironmentSettingsExporter.exe que está en el subdirectorio DeployTools.
Con esto quedé conforme pero dejaré esta configuración para más adelante, dado que ahora quiero crear un instalador con WiX
Creando el instalador con WiX
Lo primero es copiar el directorio BizTalkSample.WiXSetup y renombrarlo con NombreProyecto delante en nuestra solución, luego renombrar el BiztalkSample.WiXSetup.build con NombreProyecto delante y yo lo incluí en el directorio "Solution Items" por comodidad.
Hay que masajear un poco el archivo, no olvidar generar los GUIDs diferentes para el installer.
Luego hay que ejecutar nant en el directorio setup debajo de WixSetup (no hay path, pero está donde nosotros mismos lo copiamos 
), y no encontrará los archivos:
- InstallWizard.xml
- UnInstallWizard.xml
- CopyDeployResults.nant
que deben copiarse del directorio raíz de la solución de ejemplo a nuestro directorio raíz.
corriendo Nant luego de esto, generó el MSI.
El MSI solamente instala los archivos, y genera entradas en el menú Start para que se pueda implementar la versión. Corrí el MSI, pero no generó las entradas de implementar/desimplementar, por lo que solo me quedó ir al panel de control y desinstalar el producto, y a empezar a pensar por qué no quedó bien instalado.
Round 1- Verificar que el BtsSample funciona: Generé el instalador y lo instalé, quedando correctamente instalado.
Round 2 – Por qué no quedó instalado: . Toqué el BizTalk.WiXSetup.nant comentando la línea debajo relacionada a DeploymentTest dado que en mi ejemplo no tengo.
pero eso no ayudó, dado que provocó otro error. Creo que el error es que siempre intenta invocar con un deploymentTest aunque en el archivo NombreProyecto.sln.deploy.build yo tengo esa variable en false.
Creé entonces una solución NombreProyecto.DeploymentTest con un test que siempre de correcto. Hay que crear también un app.config con los valores que tiene el app.config de la solución de ejemplo. Creado el archivo .config, copiarlo en la raíz del proyecto.
Hecho todo esto, los errores desaparecieron, sin importar lo que hayas puesto en IncludeDeploymentTest genera el "Verify Deployment" y nada más. Esto para mí es un bug, pero tengo que investigarlo más adelante.
Lo que sí encontré es por qué no me genera el resto, es porque (y tuve que buscarlo bastante), el script generate-install-script.js de WiX modificado que está en el directorio WiXSetup\Setup, busca en la raíz del proyecto los archivos:
- ServerDeployWizard.bat
- ServerUnDeployWizard.bat
- ServerRedeployWizard.bat
- y si hay algún CHM
Para incluirlos en el menú. Estos .bat están en la raíz del directorio de la aplicación de ejemplo (junto con otros .bat que hay que copiar para que estos funcionen).
El final de la búsqueda – ¿vale la pena?
No quiero caer en la disonancia cognitiva que es lo que hace que mis amigos del pinguino piensen que "si es tan difícil, seguro que debe valer la pena, no es que soy un tarado masoquista, es que realmente vale la pena 
".
El problema al que nos enfrentamos cuando tenemos que hacer una distribución Biztalk, hoy, es que las alternativas no son buenas. Normalmente en cualquier distribución tenemos los siguientes requerimientos:
- Crear un MSI para distribuir la aplicación: esto lo realiza correctamente para Biztalk, pero nuestras assemblies personalizadas no van en el MSI para ponerlas en la GAC. Además, siempre la distribución es desde una instalación completa, no de mis propios fuentes, lo que debe ejecutarse de otra manera.
- Instalar en el ambiente: a través de la "importación" en biztalk y la distribución de los bindings, que obliga a que el operador haga la operación directamente sobre el servidor.
- Tener configuraciones personalizadas para cada ambiente: aquí la mejor opción es editar el xml de los bindings para cada caso, el uso del configurador a partir de la plantilla excel es una buena opción, dado que normalmente en otro caso lo que hacemos es dar un documento detallado de instalación para resolverlo.
Por lo anterior, pareciera que vale la pena tener toda esa infraestructura, sobretodo teniendo en cuenta la cantidad de utilitarios y casos que comprende el instalador.
Además, por lo que vi, hay dos complejidades conceptuales:
a) La complejidad conceptual de los bindings: esta complejidad es solo complejidad de comprensión, pero en la ejecución se mostró bastante simple, y la complejidad de comprensión es por dos motivos: el primero es porque el tema es complejo si no se conoce (diferentes tipos de artefactos, vinculación entre ellos, pero esto es Biztalk en sí) y el segundo es porque el encapsulamiento no está completamente terminado (y esto es porque no es un producto).
b) La complejidad grande de usar WiX para generar el MSI: aquí me encantaría saber por qué se usó WiX para este deployment en particular, dado que entiendo que por la complejidad media que tiene no sería necesario usarlo
Haciéndolo fácil, sustituyendo WiX
¿Podemos hacer esto con un proyecto de setup? Lo que necesito es:
- Generar un instalador que haga la implantación de los assemblies: esto es simple y la única ventaja que tiene el instalador actual es que puedo indicar qué quiero que se implemente y qué no y el los toma automáticamente, pero me obliga a tener los nombres de una cierta manera (lo cual a mí me parece una buena idea pero entiendo que no a todos les parezca).
- Generar los ítems de de menú para implementación: esto debería ser simple porque son puntos "semi-dinámicos" dado que solamente debo tener en cuenta si debo o no generar de cinco puntos posibles.
- Generar el script adecuado para que el instalador funcione correctamente, pero eso es simple porque eso sí es lo que se usa con Nant para implementar, esa es la parte que propongo mantener.
Así que voy a mi parte 4 y luego cuento cómo me fue.
