2008-10-06 19 views
8

Estoy construyendo una aplicación que es utilizada por varios clientes diferentes. Cada cliente tiene una buena cantidad de lógica de negocios personalizada, que he refactorizado inteligentemente en un ensamblaje que se carga en tiempo de ejecución. El nombre de ese conjunto, junto con otras configuraciones específicas del cliente, se almacenan en el archivo de configuración de la aplicación.Gestionar múltiples archivos de configuración de la aplicación durante el desarrollo

En este momento, esto es lo que tengo que hacer con el fin de depurar la aplicación de foo del cliente:

  1. Ir al sistema de archivos en mi directorio del proyecto y eliminar app.config
  2. Copia app.config.foo a app.config.foo - Copy.
  3. Renombre app.config.foo - Copy como app.config.
  4. Indica a Windows que sí, deseo cambiar la extensión del archivo.
  5. Volver a Visual Studio.
  6. Abra el artículo Settings.settings en mi proyecto.
  7. Haga clic en "Sí" 13 o 14 veces, ya que VS me pregunta si deseo usar la nueva configuración que se ha cambiado en app.config.
  8. Cerrar Settings.settings.

¡Bien! ¡Ahora estoy listo para depurar!

Me parece que el rigamarole de apertura Settings.settings es, o debe ser, innecesario: no necesito los valores predeterminados en Settings.cs para regenerar, porque no los uso. Pero es la única forma que conozco de hacer que VS sea consciente del hecho de que el archivo app.config ha cambiado, por lo que la compilación lo copiará en el directorio de salida.

Tiene que haber una manera más fácil de hacerlo. ¿Qué es?

Respuesta

2

Un par de personas sugirieron utilizar varias configuraciones de VS, lo que creo que hubiera funcionado, excepto que me exigiría reconstruir la solución cada vez que cambiara de configuración.

Lo que hice en su lugar me pareció un poco estúpido mientras lo hacía, pero lo he estado utilizando durante casi un año y funciona muy bien. En mi proyecto directamente, creo un archivo separado app.config.XXX para cada cliente. El archivo real app.config se utiliza únicamente para generar Settings.cs - tiene todos los nombres de configuración correctos y sus valores predeterminados. No se copia a los directorios de construcción, nunca.

Entonces me escribió un pequeño programa que me permite seleccionar un cliente, y que simplemente pasa a través de los directorios para cada proyecto y, si he seleccionado XXX cliente, copias app.config.XXX-bin\debug\myprogram.exe.config y bin\release\myprogram.exe.config.Mientras este programa sepa dónde está la raíz de la solución (tengo que tener un poco de cuidado cada vez que ramifique el código), funciona como un amuleto.

3

Puede consultar este post para algunas buenas prácticas: Managing Multiple Configuration File Environments with Pre-Build Events

+1

Esto funciona, aunque es un largo trabajo en torno a la funcionalidad que realmente debería estar en el IDE. – Jeremy

+0

También requiere que cree dos configuraciones (depurar y liberar) para cada cliente. Eso huele a la respuesta incorrecta para mí. –

+0

Esto funciona como un encanto. Cada ubicación (QA/DEV1/Production) tiene su propio archivo de configuración. ZERO HASSLE. Esto solo funciona ¡¡eres un genio!! Hice esto para app.config que funciona con un servicio WCF por cliente por ubicación. Funciona de maravilla. ¡eres mi héroe! –

6

También puede dejar que Visual Studio automatizar enfoque Robert`s por:

  1. definir una configuración de construcción para cada cliente
  2. En el evento posterior a la construcción, app.config.xxx simplemente xcopy a la carpeta bin . Donde XXX es el nombre de una configuración de compilación accesible en VS. Algo así como:. App.config xcopy $ (ConfigurationName) $ (OutDir) /app.config

VS dejará caer una estructura distinta para sus clientes en carpetas separadas, Aolong con el archivo de configuración adecuada. bin/Cliente1/ bin/Cliente2/

3

Pensando en el lío de la gestión de múltiples archivos de configuración que hace esta herramienta: http://envride.codeplex.com/

Su propósito es exactamente para que sea más fácil de manejar múltiples configuration files de una forma automática. Estaría muy contento si lo echarais un vistazo.

0

Después de un poco de investigación y trabajo alrededor me dieron mi proyecto de prueba se trabaja con varias configuraciones,

  1. En el Administrador de configuración, crear las configuraciones que necesita
  2. Copiar pegar su app.config y añadir el nombre de la configuración, en mi caso es AHI, FIV, MGC, por lo que mis archivos de configuración se parecen a: App.AHI.config, App.MGC.config, App.FIV.Config. Puede nombrarlo como quiera, pero mantenga la misma convención
  3. Agregue un evento Post-Build. En mi caso se vería así:. Xcopy $ aplicación (ProjectDir) $ (ConfigurationName) .config $ (TargetDir) $ (TargetName) .dll.config/a

aquí es mi post, para que pueda leer con más detalles

Running a Test Project with Multiple Configurations

Cuestiones relacionadas