Acabo de actualizar a Visual Studio 2010 y MVC 2.0 y me di cuenta de que Web.config tiene dos archivos adicionales adjuntos. ¿Se utilizan estos archivos para especificar la depuración y la liberación de configuraciones específicas, de modo que no abarrote el Web.config principal?
¿Tiene sentido colocar una cadena de conexión en el archivo raíz Web.config si tengo uno local y uno remoto en la depuración y lanzamiento de Web.configs respectivamente?
¡Gracias!
Respuestas:
Es la nueva característica de transformación Web.config de Visual Studio 2010. Más información aquí .
Editar:
¿Se utilizan estos archivos para especificar la depuración y la liberación de configuraciones específicas, de modo que no abarrote el archivo web.config principal?
No se limita a tres archivos, podría (en teoría) tener tantos archivos como entornos. El Web.config de "nivel superior" proporciona una plantilla de su configuración web. Los archivos que se encuentran debajo proporcionan valores de reemplazo específicos para ese entorno (por ejemplo, si tiene diferentes cadenas de conexión para local / stage / test / lo que sea).
¿Tiene sentido colocar una cadena de conexión en el archivo raíz web.config si tengo uno local y uno remoto en la depuración y lanzamiento de web.configs respectivamente?
Solo tendría sentido si no cambiara entre entornos. Parece que en tu caso sí lo hace, en tu caso no, no tendría sentido dejarlo en el Web.config.
Estos son archivos de transformaciones Web.config. Desde ASP.NET Web Deployment usando Visual Studio: Transformaciones de archivo Web.config :
Hay dos formas de automatizar el proceso de cambio de 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 y Release, y puede crear configuraciones de compilación personalizadas. Un perfil de publicación normalmente corresponde a un entorno de destino.
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ó mi propia forma de confiar en un archivo de propiedades por entorno.
Puede haber una mejor solución, vengo de un entorno 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:
Eso era algo que se necesitaba desde hace mucho tiempo en VS. Desafortunadamente, parece haber un problema con la implementación. Por ejemplo, considere este escenario (VS.2010 Ultimate, todos los SP):
Web.Config
Web.Release.Config
Web.Debug.Config
Al ejecutar la aplicación da el siguiente error:
El nombre de conexión 'prueba' no se encontró en la configuración de la aplicación o la cadena de conexión está vacía.
En otras palabras, debido a que los elementos de la cadena de conexión se encuentran en los archivos del diseñador Release / Debug y los utilizan los elementos de configuración en el archivo principal (Web.config), no puede resolverlo.
testen sus archivos de configuración de depuración y liberación, realmente debería estar en el web.config principal con las secciones apropiadas en la plantilla. Tal como está, está duplicando código, que es algo que se supone que la plantilla debe resolver por usted.
xsltcomandos de reemplazo explícitos . Enhorabuena por obtener 5 votos positivos por algo que aumenta la confusión sobre estos archivos de transformación :)