8

Actualmente puedo configurar fácilmente la transformación Web.config en función de la configuración de compilación, p. use connectionString=server;.. para Debug y connectionString=./SQLExpress;.. para Release.¿Es posible vincular la transformación Web.config con el perfil de publicación?

¿Pero es posible hacer algunas transformaciones Web.config basándose en el perfil de publicación web? Es decir. use connectionString=server1;.. para el perfil Server1 y connectionString=server2;.. para Server2?

Respuesta

0

Creo que los perfiles de publicación son independientes de los perfiles de compilación, lo cual es un poco lamentable, ya que podría implementar accidentalmente una configuración de depuración en sus servidores de producción.

Sin embargo, si usa MSDeploy, hay formas de modificar el archivo web.config allí. Ver MSDeploy - Changing Connection string parameter after deploying the package para más detalles.

0

Podría haber una manera ligeramente diferente de hacer esto.

En sus servidores de producción, cree una entrada ficticia, para customdb, en el archivo c: \ windows \ system32 \ drivers \ etc \ hosts en cada una de las máquinas de producción. Cada uno apunta a la base de datos que desea que use esa máquina. Entonces solo tiene que apuntar a connectionString = customdb; para todos sus servidores de producción.

El único inconveniente de esto sería que necesitaría acceder al archivo de hosts y requeriría que use un db.

Esperanza esto ayuda

+0

Interesante. Sin embargo, otro inconveniente es que no puede (fácilmente) controlar la versión del archivo de hosts, ya que contendrá configuraciones específicas de la máquina y agregará complejidad al proceso de implementación, requiriendo acceso de escritura a las rutas del sistema que normalmente debería evitar. – Abel

5

Mantenemos toda la configuración específica de la máquina/perfil de los archivos de configuración separados, a continuación, utilizar configSource incluirlos como tal ...

<connectionStrings configSource="cstrings.config"/> 

Este Web.config forma es la misma y no requiere ninguna transformación. Hacemos esto para las cadenas de conexión, la configuración smtp y la configuración de la aplicación.

Web.config de control de versiones Nosotros y "específicas de la máquina" archivos como cstrings.config.production, cstrings.config.staging, etc.

Una vez que tenga esta estructura es fácil de generar imágenes para diferentes perfiles. Tenemos scripts de implementación en cada máquina que leen una variable de entorno y se implementan adecuadamente. Por ejemplo, el script de compilación del servidor de transición copia cstrings.config.staging en cstrings.config, etc.

+0

¿Cómo se ejecutan las secuencias de comandos de implementación para vincular el perfil actual y una cadena de conexión adecuada? – abatishchev

+0

@abatishcev: Nuestro servidor de compilación tiene objetivos para pruebas, puesta en escena y producción. Se realiza un pago limpio (svn export en realidad). Construir scripts "rename $ {bin} /cstrings.config. $ {Destination} $ {bin} /cstrings.config" luego ejecutamos pruebas unitarias, zip y ftp deploy en la máquina de destino. Cada destino tiene archivos de configuración cstrings, smtp y appsettings en control de versiones. por ejemplo, cstrings.config.staging, smtp.config.staging, appsettings.config.staging. FYI: Puede dejar cstrings.config en máquinas de destino como un archivo de solo lectura si es muy consciente de la seguridad. No es un gran problema en nuestro entorno. – Rob

Cuestiones relacionadas