asp.net core connection string

Diferentes archivos de configuración para desarrollo y producción en la aplicación ASP.NET

Question

En un proyecto en el que estoy trabajando, tenemos una aplicación web con tres archivos de configuración; Web.Config Web.Config.TestServer Web.Config.LiveServer

Cuando lanzamos al servidor de prueba, Web.Config se renombra a Web.Config.Development y Web.Config.TestServer se renombra a Web.Config, activando esa configuración para la aplicación.

Es bastante oneroso mantener actualizados tres archivos de configuración muy similares, y este sistema se utiliza en una serie de aplicaciones que son parte de este proyecto; no solo el sitio web

Las diferencias en la configuración suelen ser directorios o rutas locales, URL, direcciones IP, números de puertos y direcciones de correo electrónico.

Estoy buscando una mejor manera.

Answer 1

Usa Config Transformation y hay un blog aquí al respecto.

http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

Básicamente, usted crea objetivos llamados web. {Build configuration} .config. En cada archivo de destino, escribe su transformación donde puede agregar, eliminar y modificar nodos y atributos. El ejemplo podría ser

web.staging.configss
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="personalDB"
connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" />
<add name="professionalDB"
connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
</configuration>

A continuación, ejecuta la transformación llamando a MSBuild {project file} /t:TransformWebConfig /p:Configuration=Staging

Answer 2

Si bien su enfoque parece tedioso, creo que es el mejor enfoque.

Solía ​​mantener todas mis configuraciones en un solo archivo web.config, y simplemente tenía la sección de "producción" comentada.

Poco después tuve que hacer una prueba "híbrida" donde mis datos de búsqueda provenían del servidor de producción, pero los nuevos datos se estaban insertando en la base de datos de prueba. En ese punto, tuve que empezar a analizar las partes del bloque de configuración para comentar / descomentar, y se convirtió en una pesadilla.

Del mismo modo, nuestros administradores de servidores realizan la migración real de prueba a producción, y la mayoría de ellos no son lo suficientemente fluidos en .NET para saber cómo administrar los archivos web.config. Es mucho más fácil para ellos simplemente ver un archivo .test o .prod y migrar el correcto.

Podría usar algo así como una base de datos para almacenar todas sus configuraciones, pero luego se encontrará con otra capa de abstracción y tendrá que administrar eso en la parte superior de las cosas.

Una vez que obtenga la habilidad o la plantilla de cómo se configurarán sus dos (o tres) archivos de configuración, será mucho más fácil administrarlos y puede hacer que la configuración de su servidor de prueba se modifique para algunas pruebas únicas sin mucha molestia.

Answer 3

Si tiene un servidor db en la mezcla, puede crear una tabla que tenga la configuración, el nombre de la propiedad y el valor de la propiedad en ella, entonces todo lo que tiene que hacer es cambiar un valor en el archivo web.config, el nombre de la configuración (dev, prueba, prod).

Si tiene diferentes dbs para cada configuración, entonces lo único que es diferente es la cadena de conexión.