net enable deploy asp application asp.net iis web-config

enable - Único sitio de ASP.net con múltiples instancias y web.configs



iis enable asp net (8)

Tenemos un sitio heredado 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 carpetas actual se ve algo así como: OurApp / Source aspx y default web.config
Cliente1 / Fuente aspx & web.config
Cliente2 / Fuente aspx & web.config
Cliente3 / Fuente aspx & web.config
Cliente4 / Fuente aspx & web.config
...

Esto es algo que me gustaría cambiar a cada cliente que tenga solo un archivo web.config personalizado y todos los clientes que compartan un conjunto común de archivos fuente. Algo así como: OurApp / Source aspx y default web.config
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.

Se usa el control de fuente 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 de origen? ¡Odio ese tipo de duplicación!

Dependiendo de lo que realmente se encuentre en la configuración web y de la configuración que difiera entre los clientes, puede optar por usar una sola 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.

Si está 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 conceptos básicos, ver:

El XML de ejemplo puede 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 Propiedades de ConfigSection, exponer 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 sucede detrás de escena. Simplemente usan CustomSettings.Settings.SomeSetting y no se preocupan por qué cliente está accediendo a la aplicación.

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

En realidad, no es una buena idea permitir que los ingenieros de soporte actualicen tu sitio en vivo en tiempo real.

Gracias a todos nuevamente 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.

Estoy implementando esto mientras hablamos.

En el web.config principal, tengo 1 artículo 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 usan 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 mucho. 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 personalizada de clase 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 del nombre es de solo lectura

Sé que puede parecer molesto, pero la duplicación es realmente algo bueno. 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 considerar cambiar su proceso para cambiarlo una vez implementado en todas partes. Esto hará que todo sea mucho más fácil para ti a largo plazo.

Para responder tu pregunta, la respuesta es no, no puedes 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.

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

En primer lugar, aunque no conozco su situación particular, generalmente le insto a que se quede con instalaciones separadas. 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? Estas 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 eso, digamos que quieres avanzar con esto.

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

Lo que eso significa es que tienes almacenar tu 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 enormemente compensada 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 estoy perdiendo algo!