Cómo variar la cadena de connection para diferentes ubicaciones de trabajo

Estoy trabajando en un proyecto C # 4.0, WPF 4.0, SQL 2008 y trabajo en casa y en la oficina. Acabo de configurar SubVersion usando Visual SVN según las recomendaciones que se encuentran en otras preguntas. El problema que estoy teniendo es que la cadena de connection para la database es diferente para cada location.

En casa tengo la database en mi sistema de desarrollo, en la oficina la database está en nuestro server. Ninguno de los dos está expuesto a Internet, así que tengo que usar ambos. ¿Hay una forma elegante de seleccionar automáticamente la correcta?

Actualizar

He estado teniendo problemas continuos con esto y estoy tratando de equilibrar el control de la versión de aprendizaje con el trabajo en mi proyecto. He estado leyendo el libro de subversión y estoy de acuerdo con lo que cubre. Mi único problema real es tratar con files que necesitan variar adecuadamente entre entornos de desarrollo. Podría codificar fácilmente mi path alnetworkingedor de esto, pero eso me parece un poco raro. Veo más de un par de artículos sobre lo raro que puede ser el svn: exclude y me parece que lo que funciona en casa está causando problemas en el trabajo y viceversa.

Tal vez simplemente no sé lo suficiente como para reconocer la respuesta correcta, así que por favor apúntame en la dirección correcta (no necesito que lo hagas por mí) o sube la mejor respuesta existente y continuaré mi investigación.

Gracias

Si realmente quiere automatizar esto por completo, podría hacer algo como esto:

Primero, almacene las configuraciones para los diferentes entornos en el control de fuente, pero no en el file de configuration real. Por ejemplo:

configfiles\app.config.mikeb_home configfiles\app.config.local configfiles\app.config.development configfiles\app.config.staging configfiles\app.config.production 

Luego, en la configuration de compilation, puede agregar un paso para copyr el file de configuration correcto en su aplicación raíz.config. Por ejemplo, con un 'evento de preconstrucción' (script de command-line) basado en parameters 'de entorno' (nombre de equipo, nombre de usuario, …). Probablemente pueda lograr lo mismo agregando algunos commands msbuild en el file .csproj.

Sin embargo, ¿todo esto realmente lo vale? TortoiseSVN tiene una característica llamada list 'ignorar-en-comprometer', que le ayuda a prevenir accidentalmente la confirmación de un file cambiado localmente que no debe ser comprometido (en el dialog de confirmación, haga clic derecho en el file => Mover a la list de cambios – > ignorar-en-comprometer). Puede ser un poco molesto si realmente necesita cambiar algo más en el file .config, pero aún así.

Simple: no coloque la cadena de connection en el código, léala de los datos de configuration en alguna parte. Y luego simplemente no ponga esos datos de configuration en Subversion.

En una aplicación en la que estoy trabajando ahora, almacenamos la información de la cadena de connection en el logging de Windows, en HKLM \ Software \ [OurProduct] \ Database.

¿No puedes cambiar el .config en casa y no volver a comprobar el cambio en la cadena de connection?

Mantener la información de la cadena de connection en el código es una mala práctica (cualquiera puede usar ildasm.exe y ver todas las cadenas en su código).

Este tipo de información debe estar en una configuration sobre la que tenga mejor control.

Además, .NET admite el encryption de la sección de cadena de connection , si es necesario.

Creo que la solución ideal sería utilizar algo así como las transformaciones web.config que se están agregando en Visual Studio 2010. Desafortunadamente, por lo que yo sé, estas solo están disponibles para los files web.config.

puede usar configuraciones para definir más de una cadena de connection. simplemente haga doble clic en Configuraciones. Configuraciones desde Solution Explorer-> project-> Properties. luego verá el cuadro combinado que contiene types de configuraciones. elija ConnectionString y luego ingrese el connstr.

entonces puedes get el connstr con el siguiente código

 using System.Configuration; using test.Properties; namespace test{ public partial class mainForm : Form{ public mainForm() { InitializeComponent(); } private void mainForm_Load(object sender, EventArgs e) { string connectionStr = ConfigurationManager.ConnectionStrings[this_index_is_up_to your_algorithm].ToString(); } } 

}

En el control de fuente, use la cadena de connection en app.config que se utiliza para la cadena de connection más comúnmente utilizada (probablemente sea el trabajo).

En casa, secuestrar (o retirar) el file que selecciona qué cadena de connection usar, y editarlo para usar la cadena de connection de tu casa.

.NET tiene una forma de anular la configuration en un file de configuration de aquellos en otro utilizando el atributo de file . Usualmente hacemos algo como esto:

web.config

 <configuration> <appSettings file="web.custom.config"> <!-- your default settings here --> </appSettings> </configuration> 

web.custom.config

 <appSettings> <!-- override stuff from root web.config here here --> </appSettings> 

Por convención, configuramos nuestro sistema de control de fuente [SVN] para ignorar cualquier file custom.config. Esto nos permite verificar el núcleo, la configuration pnetworkingeterminada y, a la vez, permitir que cada desarrollador administre la configuration específica del entorno.

Nota: esto solo funciona con la <appSettings> . Si está almacenando cadenas de connection en la key <connectionStrings> , considere mover esas configuraciones a appSettings en su lugar.

Ver http://msdn.microsoft.com/en-us/library/ms228154.aspx