Sitio único ASP.net con varias instancias y web.configs

Question

Tenemos un sitio heredado de ASP.net que se ejecuta en un servidor IIS, el sitio fue desarrollado por un equipo central y es utilizado por varios clientes. Sin embargo, cada cliente tiene su propia copia de los archivos aspx del sitio más un archivo web.config. Esto está causando problemas, ya que los cambios realizados por los ingenieros de soporte de buenas intenciones a las copias de los archivos fuente aspx no se vuelven a plegar en la fuente central, por lo que nuestra base de código es divergente. Nuestra estructura de la carpeta actual se ve algo como: OurApp/Fuente web.config aspx & predeterminado
Customer1/Fuente aspx & web.config
Customer2/Fuente aspx & web.config
Customer3/Fuente aspx & web.config
Customer4/Fuente aspx & web.config
...

Esto es algo que me gustaría cambiar a cada cliente que tiene sólo un archivo web.config personalizada y todos los clientes compartir ac ommon conjunto de archivos de origen. Así que algo como: OurApp/Fuente web.config aspx & predeterminado
Customer1/web.config
Customer2/web.config
Customer3/web.config
Customer4/web.config
...

Entonces mi pregunta es, ¿cómo configuro esto? Soy nuevo en ASP.net e IIS ya que suelo usar PHP y Apache en casa pero utilizamos ASP.net e ISS aquí en el trabajo.

---

control Fuente se utiliza y tengo la intención de capacitar a los ingenieros de soporte, pero ¿hay alguna manera de evitar tener múltiples copias de los archivos aspx fuente? ¡Odio ese tipo de duplicación!

Answer 1

Si está configurado como inactivo en la instancia de aplicación única, puede lograr lo que busca después de usar una sección de configuración personalizada en su único web.config. Para los fundamentos, ver:

• http://haacked.com/archive/2007/03/12/custom-configuration-sections-in-3-easy-steps.aspx
• http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

Ejemplo XML podría ser:

<YourCustomConfigSection> 
    <Customers> 
    <Customer Name="Customer1" SomeSetting="A" Another="1" /> 
    <Customer Name="Customer2" SomeSetting="B" Another="2" /> 
    <Customer Name="Customer3" SomeSetting="C" Another="3" /> 
    </Customers> 
</YourCustomConfigSection> 

Ahora en sus propiedades configSection, exponga Nombre, SomeSetting, y otro. Cuando se accede a la Propiedad o se establece, use una condición (dominio de solicitud u otra cosa que identifique de manera única al Cliente) para decidir cuál usar.

Con la implementación adecuada, los desarrolladores de la aplicación no necesitan estar al tanto de lo que ocurre entre bastidores. Simplemente usan CustomSettings.Settings.SomeSetting y no se preocupan por qué cliente está accediendo a la aplicación.

Answer 2

Utilice una aplicación de control de fuente externa y siga implementando actualizaciones según sea necesario.

No es realmente una buena idea dejar que los ingenieros de soporte actualicen su sitio en vivo en tiempo real de todos modos.

Answer 3

Sé que puede parecer molesto, pero la duplicación es realmente una buena cosa. El problema aquí es con su proceso, no con la forma en que se configuran los sistemas.

Mantener los sitios separados es realmente una buena cosa. Aunque parece "duplicación", en realidad no lo es. Es separación. Se debe desalentar activamente la realización de cambios en el código de producción por parte de los ingenieros de soporte.

Debería estar buscando cambiar su proceso para cambiarlo una vez que se implemente en todas partes. Esto hará que todo sea mucho más fácil para ti a largo plazo.

Para responder realmente a su pregunta, la respuesta es no, no puede hacerlo. La razón es que web.config no está diseñado para almacenar configuraciones de nivel de usuario, está diseñado para almacenar por configuración de instancia de la aplicación. En su caso, necesita una instancia de aplicación por usuario, lo que significa archivos de configuración separados.

Para que su sistema funcione, debe poder decirle de manera preventiva a la aplicación qué archivo de configuración usar, lo cual no es posible sin algún tipo de información del usuario.

Answer 4

Dependiendo de qué hay realmente en la configuración web y qué configuraciones difieren entre los clientes, puede optar por usar una única configuración web y almacenar otras opciones de configuración específicas del cliente en una base de datos u otro archivo xml/texto personalizado. Siempre que la configuración específica del cliente en web.config no tenga que ver con la forma en que opera IIS, y usted solo la está usando para almacenar valores, entonces esta solución podría funcionar bien para usted.

Answer 5

Si entiendo correctamente, parece que tiene varias implementaciones (una para cada cliente) donde la única diferencia es la web.config, ¿verdad?

En primer lugar, aunque no conozco su situación particular, generalmente le insto a que se quede con las instalaciones por separado. Por lo general, permite mucha más flexibilidad. Por encima de todo: ¿alguna vez vas a tener personalizaciones o clientes diferentes que ejecuten versiones diferentes? ¿Eres seguro? La forma más fácil de mantenerse flexible aquí es continuar con las instalaciones por separado.

En mi opinión, no es feo si sus prácticas están alineadas correctamente. En función de algunas cosas que mencionó, tiene problemas en esa área, obviamente, posibles problemas de compra/capacitación de control de fuente. Pero estás enterado de eso. También examinaría detenidamente los procedimientos de implementación, etc. Tengo la sensación de que podría haber más problemas en esa área, y no me refiero absolutamente a la ofensa.

Dicho esto, supongamos que quiere seguir adelante con esto.

No dijo si todos los clientes comparten una sola base de datos común, pero estoy pensando que no, ya que diseñar ese tipo de sistema a menudo no justifica la complejidad adicional (que puede ser grave en sistemas de cualquier tamaño) entonces la gente a menudo opta por mantenerlos separados.

Lo que eso significa es que tiene almacenar su cadena de conexión en alguna parte. Usualmente eso sería web.config ... Entonces eso parece romper nuestro plan.

En realidad, la aparente elegancia de esta situación casi siempre se ve ampliamente contrarrestada por los desafíos que presenta. Si lo hubiera pensado lo suficiente, podría encontrar una forma de evitar esto introduciendo otra base de datos que administre inteligentemente las cadenas de conexión o tal vez profundice en mantener toda su información de inicio de sesión directamente en web.config (lo cual es posible pero ... no es ideal) Sin embargo, mi instinto me dice que el trabajo se desperdiciará porque algún día terminarás volviendo a cómo lo estás haciendo ahora.

También: cambiar código directamente en producción obviamente no es la mejor práctica aquí. Pero si estás en una plataforma compartida monolítica con cualquier cantidad de tráfico, eso nunca podrá suceder. Comida para el pensamiento.

¡Avísame si me falta algo!

Answer 6

Bueno, podrías intentar utilizar enlaces duros: http://msdn.microsoft.com/en-us/library/aa365006.aspx ... lo pediste.

Otra cuestión que podría ser de interés: Techniques For Distributing ASP.NET User Controls Across Projects

Answer 7

Gracias a todos por sus respuestas. Después de leerlos y de pensar lo que creo que haré es dejar las múltiples instancias en paz por ahora e intentaré mejorar primero nuestro proceso de actualización. luego desarrollaré una nueva versión de la aplicación que tiene la información de configuración del usuario en la capa de la base de datos y luego elegiré al usuario según el dominio de solicitud o la URL que alguien sugirió. De esta forma, puedo tener una sola instancia de aplicación que admita múltiples configuraciones de cliente diferentes limpiamente.

Como la mayoría de los datos de configuración del cliente están realmente relacionados con la presentación o la fuente de datos, nada complicado. Creo que terminamos con varias instancias de aplicaciones principalmente porque el programador original no había esperado varios clientes y no diseñó para eso, así que cuando alguien llegó más tarde y agregó un segundo cliente, simplemente duplicaron la aplicación, lo cual es un desperdicio ya que cada instancia es aproximadamente 99.99% idéntico al original.

Answer 8

Estoy implementando esto mientras hablamos.

En la web.config principal, tengo 1 elemento por instalación. Me señala el archivo de configuración personalizado que construí para cada cliente (y hacia la página maestra personalizada, css, imágenes, etc.).

Usando WebConfigurationManager.OpenWebConfiguration, abro los nuevos webconfigs en sus subdirectorios. Determino cuál usar utilizando System.Web.HttpContext.Current.Request.Url.OriginalString y determinando el uRL que me llamó. Basado en esa URL, sé qué web.config usar.

A partir de ese momento, todos los clientes utilizan la misma base de código. Ellos tienen sus propias bases de datos también.

La idea de tener que actualizar 30-40 instalaciones cuando realizamos una actualización me asusta hasta la muerte. No queremos admitir 30-40 bases de código, por lo que no habrá personalización más allá de la página maestra, css e imágenes.

Escribí una lib de clase personalizada que sabe cómo cambiar al webconfig apropiado, y leí la sección personalizada que construí con todas nuestras configuraciones.

El único problema que tengo ahora es la cookie FormsAuthentication. Necesito poder cambiar eso también. Desafortunadamente, la propiedad para el nombre es de solo lectura