asp.net - ¿Para qué sirven los archivos Web.Debug.config y Web.Release.Config?
asp.net-mvc visual-studio-2010 (4)
En caso de que alguien esté interesado, aquí hay algo que escribí para tener una cadena de conexión dinámica por entorno. Quería implementar el código en cualquier entorno (Dev, Test, Pre-Prod, Prod ...) sin tener que preocuparme por cambiar las cadenas de conexión. Realmente no pude encontrar una buena manera de hacer esto con Asp.Net MVC 4, así que se me ocurrió la manera de confiar en un archivo de propiedades por entorno.
Puede haber una solución mejor, vengo de un fondo de Wicket / Java y recientemente comencé a desarrollar con MVC 4 por lo que es posible que exista una mejor solución. Pero aquí hay un enlace a mi pregunta y respuesta para una cadena de conexión dinámica:
Acabo de actualizar a Visual Studio 2010 y MVC 2.0 y me di cuenta de que Web.config tiene dos archivos adicionales conectados a él. ¿Se utilizan estos archivos para especificar ajustes específicos de depuración y liberación, para que no ocupe demasiado el Web.config principal?
¿Tiene sentido incluso colocar una cadena de conexión en el archivo raíz Web.config si tengo uno local y remoto en la depuración y liberar Web.configs respectivamente?
¡Gracias!
Es la nueva característica de transformación de Web.config de Visual Studio 2010. Más información aquí .
Editar:
¿Se utilizan estos archivos para especificar ajustes específicos de depuración y liberación, para que no ocupe demasiado el web.config principal?
No está limitado a tres archivos, podría (en teoría) tener tantos archivos como entornos tenga. El "nivel superior" Web.config proporciona una plantilla de su configuración web. Los archivos debajo de este proporcionan valores de reemplazo específicos para ese entorno (como si tiene diferentes cadenas de conexión para local / stage / test / whatever).
¿Tiene sentido incluso colocar una cadena de conexión en el archivo raíz web.config si tengo una local y remota en la depuración y liberar web.configs respectivamente?
Tendría sentido si no fuera a cambiar entre entornos. Parece que en su caso sí, en su caso no, no tendría sentido dejarlo en el Web.config.
Eso fue algo necesario en VS. Desafortunadamente, parece haber un problema con la implementación. Por ejemplo, considere este escenario (VS.2010 Ultimate, todos SP):
Web.Config
- Sin conexiónSección de cadenas
- Membresía completa Usuario / Rol / etc. Configuración del proveedor usando connectionStringName = "test"
Web.Release.Config
- Sin configuración de membresía (ya se ha especificado en web.config principal)
- sección connectionStrings que incluye la CS llamada "prueba"
Web.Debug.Config
- Sin configuración de membresía (ya se ha especificado en web.config principal)
- sección connectionStrings que incluye la CS llamada "prueba"
Al ejecutar la aplicación se produce el siguiente error:
El nombre de conexión ''prueba'' no se encontró en la configuración de las aplicaciones o la cadena de conexión está vacía.
En otras palabras, como los elementos de la cadena de conexión están en los archivos del diseñador Release / Debug y son utilizados por los elementos de configuración en el archivo principal (Web.config), no puede resolverlo.
Estos son archivos de transformaciones Web.config. Desde la implementación web de ASP.NET utilizando Visual Studio: Transformaciones de archivos Web.config :
Hay dos formas de automatizar el proceso de cambiar la configuración del archivo Web.config: transformaciones Web.config y parámetros de Web Deploy. Un archivo de transformación Web.config contiene marcado XML que especifica cómo cambiar el archivo Web.config cuando se implementa. Puede especificar diferentes cambios para configuraciones de compilación específicas y para perfiles de publicación específicos. Las configuraciones de compilación predeterminadas son Debug and Release, y puede crear configuraciones de compilación personalizadas. Un perfil de publicación normalmente corresponde a un entorno de destino.