asp.net - studio - Usar diferentes Web.config en el entorno de desarrollo y producción
iis debug visual studio (9)
¿Has buscado proyectos de implementación web?
También hay una versión para VS2005, si no está en 2008.
Necesito usar una cadena de conexión de base de datos diferente y una dirección de servidor SMTP en mi aplicación ASP.NET, dependiendo de si se ejecuta en un entorno de desarrollo o producción.
La aplicación lee la configuración del archivo Web.config a través de la propiedad WebConfigurationManager.AppSettings .
Utilizo el comando Build / Publish para implementar la aplicación al servidor de producción a través de FTP y luego reemplazar manualmente el Web.config remoto con el correcto.
¿Es posible de alguna manera simplificar el proceso de implementación? ¡Gracias!
El editor de configuración de Enterprise Library puede ayudarlo a hacer esto. Le permite crear un archivo de configuración base y luego deltas para cada entorno. A continuación, puede fusionar la configuración base y el delta para crear un web.config específico del entorno. Eche un vistazo a la información here que lo guiará a través de ella mejor que yo.
En Visual Studio 2010 y superior, ahora tiene la capacidad de aplicar una transformación a su web.config dependiendo de la configuración de compilación.
Al crear un web.config, puede expandir el archivo en el explorador de soluciones y verá dos archivos:
- Web.Debug.Config
- Web.Release.Config
Contienen un código de transformación que se puede usar para
- Cambiar la cadena de conexión
- Eliminar la configuración y el registro de depuración
- Registrar páginas de error
Consulte la sintaxis de transformación de Web.config para la implementación de proyectos de aplicaciones web en MSDN para obtener más información.
También es posible, aunque oficialmente no sea compatible, aplicar el mismo tipo de transformación a un archivo app.config aplicación no web. Vea el blog de Phil Bolduc sobre cómo modificar su archivo de proyecto para agregar una nueva tarea a msbuild.
Esta es una solicitud larga y resistente en Visual Studio Uservoice .
Una extensión para Visual Studio 2010 y superior, " SlowCheetah ", está disponible para encargarse de crear la transformación para cualquier archivo de configuración. A partir de Visual Studio 2017.3, SlowCheetah se ha integrado en el IDE y Microsoft administra la base de código. Esta nueva versión también admite la transformación JSON.
En un proyecto en el que teníamos 4 entornos (desarrollo, prueba, puesta en escena y producción), desarrollamos un sistema en el que la aplicación seleccionaba la configuración adecuada en función del nombre de la máquina en la que se implementaba.
Esto funcionó para nosotros porque:
- los administradores podrían implementar aplicaciones sin involucrar a los desarrolladores (un requisito) y sin tener que jugar con los archivos de configuración (que odiaban);
- nombres de máquinas adheridos a una convención. Emparejamos nombres usando una expresión regular y desplegamos en varias máquinas en un entorno; y
- utilizamos seguridad integrada para las cadenas de conexión. Esto significa que podríamos mantener los nombres de las cuentas en nuestros archivos de configuración en el momento del diseño sin revelar ninguna contraseña.
Funcionó bien para nosotros en este caso, pero probablemente no funcionaría en todas partes.
Este es uno de los grandes beneficios del uso de la máquina.config. En mi último trabajo, tuvimos entornos de desarrollo, prueba y producción. Podríamos usar machine.config para cosas como cadenas de conexión (a la máquina SQL apropiada, dev / test / prod).
Puede que esta no sea una solución para usted si no tiene acceso a la máquina de producción real (por ejemplo, si estaba usando una empresa de alojamiento en un host compartido).
La etiqueta <appSettings> en web.config admite un atributo de archivo que cargará una configuración externa con su propio conjunto de clave / valor. Esto anulará cualquier configuración que tenga en su web.config o agregará a ellos.
Aprovechamos esto al modificar nuestro web.config en el momento de la instalación con un atributo de archivo que coincide con el entorno en el que se está instalando el sitio. Hacemos esto con un interruptor en nuestro instalador.
p.ej;
<appSettings file="./EnvironmentSpecificConfigurations/dev.config">
<appSettings file="./EnvironmentSpecificConfigurations/qa.config">
<appSettings file="./EnvironmentSpecificConfigurations/production.config">
Nota:
- Los cambios en .config especificados por el atributo no activarán un reinicio del proceso de trabajo asp.net
Me gustaría saber, también. Esto ayuda a aislar el problema para mí
<connectionStrings configSource="connectionStrings.config"/>
Luego guardo un connectionStrings.config, así como un "{host} connectionStrings.config". Todavía es un problema, pero si hace esto para las secciones que difieren en los dos entornos, puede implementar y versión del mismo web.config.
(Y yo no uso VS, por cierto).
También podría hacer que sea un paso posterior a la construcción. Configure una nueva configuración que sea "Implementar" además de Depurar y liberar, y luego haga que el paso posterior a la compilación copie sobre el web.config correcto.
Usamos compilaciones automáticas para todos nuestros proyectos, y con ellas el script de construcción actualiza el archivo web.config para que apunte a la ubicación correcta. Pero eso no lo ayudará si está haciendo todo, desde VS.
Utilizo una secuencia de comandos de compilación NAnt para implementar en mis diferentes entornos. Lo tengo modificar mis archivos de configuración a través de XPath dependiendo de dónde se están implementando, y luego automáticamente los pone en ese entorno usando Beyond Compare .
Demora uno o dos minutos en configurarse, pero solo necesita hacerlo una vez. Luego, los archivos por lotes se hacen cargo mientras tomo otra taza de café. :)
Here''s un artículo que encontré en él.