Desarrollo vs Producción: Cadenas de conexión

Question

Estoy en el proceso de mover el servidor SQL a una máquina separada. Actualmente estamos ejecutando nuestro servidor web y servidor sql en el mismo cuadro. Entonces tenemos un servidor de producción con IIS y SQLServer y luego un servidor de desarrollo separado que refleja esta configuración.

Cuando se trata de nuestra app.config de control de asp.net y del sitio web web.config, esto funcionó bien porque pudimos usar "Initial Catalog = MyDB; ..." y funcionó porque el nombre de DB era el lo mismo en ambas máquinas.

Ahora estoy buscando ejecutar ambas bases de datos en el mismo cuadro (MyDB, MyDB-Dev). ¿Existe una manera fácil de hacerlo sin tener que editar web.config y app.config cada vez que implementamos o compilamos? ¿Es esto algo que Visual Source Safe podría manejar?

Answer 1

Aquí está la solución que uso. En la web.Config, coloque el siguiente "incluir" línea:

<connectionStrings configSource="WebCS.config"/> 

A continuación, crear el archivo WebCS.config e introduzca la siguiente:

<connectionStrings> 
<add name="ConnString" 
    connectionString="Data Source=YourServer;Initial Catalog=YourDB;etc.. 
    providerName="System.Data.SqlClient"/> 
</connectionStrings> 

Entonces, después de publicar su sitio en VS, retire los WebCS. archivo de configuración (tengo un archivo por lotes para hacer esto) antes de agrupar todo lo demás para la transferencia a la nueva máquina. A continuación, tendrá la seguridad de que todos los ajustes del archivo Web.Config le acompañarán sin interferir con su cadena de conexión.

Answer 2

Es posible que no entienda completamente su pregunta aquí, pero me parece que cuando implementa la aplicación, simplemente no puede volver a implementar la web.config a menos que haya cambios en la web.config que deba realizarse . En otras palabras, copie todos los archivos en el directorio excepto el archivo web.config.

Si tiene que cambiar el archivo web.config entre las implementaciones, deberá editar el archivo web.config para cada servidor.

Alternativamente, podría encontrar otro lugar en cada máquina para almacenar las cadenas de conexión que no sean web.config.

Answer 3

Implementar web.config casi nunca es una copia del archivo de dev a prod. Es normal tener entradas diferentes, p. su sitio web de desarrollo apunta a una base de datos local o un cuadro de base de datos de desarrollo y su sitio web de productos generalmente tiene que apuntar a su cuadro de base de datos prod.

Al implementar, su producción web.config por lo general solo necesita cambiarse si ha realizado cambios de arquitectura en su aplicación que requieren nuevos elementos de configuración o si desea eliminar los redundantes.

Con control de fuente, la práctica habitual es excluir web.config y tener un archivo de plantilla que se puede utilizar como base para crear un archivo de configuración, p. web.config.template. Al realizar cambios estructurales en web.config, debe realizar los cambios en web.config.template, luego hacer copias de él para dev y prod, y aplicar los ajustes dev y prod en consecuencia.

Answer 4

Uso NAnt para compilar e implementar. Realizo mis archivos .config en plantillas usando la convención de nomenclatura .config.template. Tengo una propiedad NAnt llamada "entorno" que configuro desde la línea de comando para NAnt. En la parte superior de mi build.xml, configuré una propiedad "db.connectionstring" basada en la propiedad "environment" (como una declaración switch). En la tarea de compilación, utilizo grep para insertar la cadena "db.connectionstring" en el lugar de la plantilla para la salida del directorio de compilación. De esta manera, sólo necesita llamar:

nant -D:environment=dev 

esto se pone un conjunto-dev específico de archivos .config.

Si no te gusta grep, siga esto:

http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/

Esto sólo funciona para archivos XML. Grep es más genérico. De hecho, tengo diferentes nombres de bases de datos basados ​​en el entorno de despliegue, y grep me permite insertar diferentes nombres de bases de datos en scripts SQL basados ​​en el entorno.

Answer 5

a extraer el atributo configSource del elemento connectionStrings en el web.config

que debería hacer más fácil lo suficientemente

Answer 6

Sólo por lo que me queda claro, su entorno actual es de dos servidores, es decir

Dev Aplicación/servidor DB
Producción Aplicación/servidor DB

y usted está pensando en lo que es algo como esto

servidor de aplicaciones (dev + producción)
DB Server (dev + producción)

Si ese es el caso, te felicito por el aislamiento de la base de datos y la aplicación en dos servidores independientes - cuando se pasa de un entorno de servidor único ese es el primer paso, ya que permite una fácil actualización más adelante si necesita agrupar varios servidores de BD o (más comúnmente) equilibrar la carga de múltiples servidores web frente a un solo servidor de BD para ayudar al rendimiento de la aplicación.

Habiendo dicho eso, no sugiero que se ejecuten los entornos de desarrollo y producción uno al lado del otro como este en el mismo servidor. Si bien puede tener sentido financiero, el propósito de un entorno de desarrollo aislado es evitar que los "errores de desarrollo" se propaguen a la producción, y hacerlo de esta manera puede llevar a un tiempo de inactividad si tiene algún código incorrecto que llegue al entorno de desarrollo.

Answer 7

¿Puede poner todas las cadenas de conexiones en el archivo web.config y luego en un punto principal de la aplicación determinar cuál usar en función del servidor de la aplicación?

Answer 8

Para el desarrollo, use un archivo Web.Debug.config, y para la producción, use Web.Release.config. Cada uno puede definir su propia cadena de conexión separada.