2010-10-19 11 views
18

Tenemos un sitio web ASP.NET que usa el estado de sesión del servidor SQL. El estado se configura en Web.config como:Configurar estado de sesión ASP.NET en tiempo de ejecución

<sessionState mode="SQLServer" sqlConnectionString="data source=TheServer; 
    User ID=TheUser;password=ThePassword;" cookieless="false" timeout="480"/> 

Pero hay tres ambientes (desarrollo/montaje/producción). Todas las otras cadenas de conexión se configuran como:

<configuration> 
    <connectionStrings> 
     <add name="Development_Db1" connectionString="..."/> 
     <add name="Production_Db1" connectionString="..."/> 
    </connectionStrings> 
</configuration> 

En tiempo de ejecución, elegimos uno para conectarse a la base de datos basado en host. Desafortunadamente, la cadena de conexión del estado de la sesión parece estar codificada en el web.config.

¿Hay alguna forma de configurar el estado de la sesión del servidor SQL en tiempo de ejecución o hacer que se refiera a una cadena de conexión de la sección connectionStrings?

+0

¿Básicamente tiene información de todos los entornos en un archivo de configuración? ¿No quieres usar un archivo por entorno? –

+0

@ GôTô: Sí, toda la información para todos los entornos está en un archivo de configuración. Trabajando en un sistema relativamente antiguo aquí, mi trabajo es cambiarlo del estado en proceso al estado sqlserver. – Andomar

+1

Esta es una buena pregunta en general, pero no me gusta la idea de mantener todas las cadenas de conexión en un solo lugar. Demasiadas posibilidades de que la producción escriba en el entorno de desarrollo o viceversa ... – RedFilter

Respuesta

17

Al final resultó que, había una manera bastante fácil de hacer esto Session State proporciona una función llamada Partitioning, donde puede distribuir su estado en múltiples servidores SQL. Puede proporcionar una función para seleccionar el servidor SQL en función de la id. De sesión (SID). El truco es que puede usar esta característica con UN servidor, solo para elegir el servidor dinámicamente.

La configuración web.config parece:

<sessionState mode="SQLServer" 
       partitionResolverType="YourNamespace.PartitionResolver" 
       cookieless="false" 
       timeout="60" /> 

La función que elige el SQL Server se ve así:

public class PartitionResolver : IPartitionResolver 
{ 
    public void Initialize() {} 

    // The key is a SID (session identifier) 
    public String ResolvePartition(Object key) 
    { 
     return <grab your config here>; 
    } 
} 

Este enfoque nos permite continuar utilizando uno web.config tanto para la producción y el desarrollo .

+1

+1 para una solución genial y simple. Funciona de maravilla – JOpuckman

1

De acuerdo con este artículo, se puede personalizar el proveedor de estado de sesión:

http://www.exforsys.com/tutorials/asp.net-2.0/asp.net-2.0-customizing-the-session-state-mechanism.html

La información que aquí se podría utilizar para diseñar un proveedor de estado de sesión consciente del entorno que puedan seleccionar la cadena de conexión basada en una configuración en el archivo .config u otra clave ambiental.

+0

Tendría que volver a implementar el proveedor de estado de sesión SQL? Ouch – Andomar

+0

No querrá volver a implementarlo totalmente. Desearía tratar de superponer un mecanismo de descubrimiento de cadena de conexión SQL personalizado sobre el proveedor de sesión SQL existente. –

+0

Pero el proveedor de sesión SQL existente usa la cadena de conexión del 'Web.config'. Entonces, ¿cómo podría volver a usar eso? – Andomar

3

Como se mencionó anteriormente, creo que no debería tener cadenas de conexiones de desarrollo y prod en la web.config. Puede usar un proyecto de implementación web para resolver ese problema. Puede usar un proyecto de implementación web para reemplazar su configuración basada en la compilación. Por ejemplo, podría tener dos archivos de configuración externos llamados connectionStrings.dev.config y connectionStrings.prod.config. Si compila en Debug, usaría dev.config, pero si crea en Release, usaría prod.config.

Es un poco diferente de VS 08 y 10. Estas son algunas de las referencias:

VS 2008 - http://johnnycoder.com/blog/2010/01/07/deploy-aspnet-web-applications-with-web-deployment-projects/

VS 2010 - http://www.hanselman.com/blog/WebDeploymentMadeAwesomeIfYoureUsingXCopyYoureDoingItWrong.aspx

Cuestiones relacionadas