Configura stato sessione ASP.NET in fase di esecuzione

Abbiamo un sito Web ASP.NET che utilizza lo stato sessione di SQL Server. Lo stato è configurata in Web.config come:Configura stato sessione ASP.NET in fase di esecuzione

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

ma ci sono tre ambienti (sviluppo/staging/produzione). Tutte le altre stringhe di connessione sono configurate come:

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

In fase di esecuzione, ne selezioniamo uno per connettersi al database in base al nome host. Sfortunatamente, la stringa di connessione Session State sembra codificata in modo rigido in web.config.

Esiste un modo per configurare lo stato della sessione di SQL Server in fase di esecuzione o fare riferimento a una stringa di connessione dalla sezione connectionStrings?

fonte

2010-10-19 Andomar

Quindi in pratica si hanno le informazioni di tutti gli ambienti in un unico file di configurazione? Non vuoi usare un file per ambiente? –

@ GôTô: Sì, tutte le informazioni per tutti gli ambienti si trovano in un unico file di configurazione. Lavorando su un sistema relativamente vecchio qui, il mio compito è quello di passare dallo stato in-process allo stato sqlserver. – Andomar

Questa è una buona domanda in generale, ma non mi piace l'idea di mantenere tutte le stringhe di connessione in un unico punto. Troppe possibilità che la produzione scriva in ambiente di sviluppo o viceversa ... – RedFilter

Come si è scoperto, c'era un modo abbastanza facile di fare questo. Stato sessione fornisce una funzionalità denominata Partitioning, in cui è possibile distribuire lo stato su più server SQL. È possibile fornire una funzione per selezionare SQL Server in base all'id di sessione (SID). Il trucco è che puoi usare questa funzionalità con UN server, solo per scegliere il server in modo dinamico.

La configurazione web.config assomiglia:

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

La funzione che sceglie di SQL Server si presenta come:

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

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

Questo approccio ci ha permesso di continuare ad utilizzare uno web.config sia per la produzione e lo sviluppo .

fonte

2011-01-23 00:48:54 Andomar

+1 per un'ottima e semplice soluzione. Funziona come un fascino – JOpuckman

In base a questo articolo, è possibile personalizzare il provider di stato di sessione:

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

Le informazioni qui potrebbe essere usato per progettare una sessione fornitore stato consapevole dell'ambiente che potrebbe selezionare la stringa di connessione basata su un configurazione nel file .config o qualche altra chiave ambientale.

fonte

2010-10-19 16:04:47

Dovrei reimplementare il provider SQL Session State? Ouch – Andomar

Non vorresti re-implementarlo completamente. Si vorrebbe provare a sovrapporre un meccanismo di individuazione delle stringhe di connessione SQL personalizzato sul provider di sessioni SQL esistente. –

Ma il Session Provider SQL esistente utilizza la stringa di connessione da "Web.config". Quindi come potrei riutilizzarlo? – Andomar

Come accennato in precedenza, penso che non dovresti avere entrambe le stringhe di collegamento dev e prod in web.config. È possibile utilizzare un progetto di distribuzione Web per risolvere il problema. È possibile utilizzare un progetto di distribuzione Web per sostituire le impostazioni di configurazione in base alla generazione. Ad esempio, potresti avere due file di configurazione esterni chiamati connectionStrings.dev.config e connectionStrings.prod.config. Se costruisci in Debug, userebbe il file dev.config, ma se si crea in Release, si userebbe prod.config.

E 'un po' diverso da VS 08 e 10. Qui ci sono alcuni riferimenti:

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

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

fonte

2010-10-19 17:21:56

Configura stato sessione ASP.NET in fase di esecuzione

risposta

Problemi correlati