2010-10-19 4 views
18

Nous avons un site Web ASP.NET qui utilise l'état de session SQL Server. L'état est configuré en Web.config comme:Configurer l'état de session ASP.NET au moment de l'exécution

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

Mais il y a trois environnements (développement/mise en scène/production). Toutes les autres chaînes de connexion sont configurées comme:

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

Lors de l'exécution, nous sélectionnons un pour se connecter à la base de données basée sur le nom d'hôte. Malheureusement, la chaîne de connexion Etat de session semble être codée en dur dans web.config.

Existe-t-il un moyen de configurer l'état de la session SQL Server lors de l'exécution ou de le faire se référer à une chaîne de connexion de la section connectionStrings?

+0

Donc, fondamentalement, vous avez des informations sur tous les environnements dans un fichier de configuration? Voulez-vous pas utiliser un fichier par environnement? –

+0

@ GôTô: Oui, toutes les informations pour tous les environnements sont dans un fichier de configuration. Travaillant sur un système relativement ancien ici, mon travail consiste à l'échanger de l'état in-process à l'état sqlserver. – Andomar

+1

C'est une bonne question en général, mais je n'aime pas l'idée de garder toutes les chaînes de connexion en un seul endroit. Trop de chance que la production écrit dans l'environnement de développement ou vice versa ... – RedFilter

Répondre

17

En fait, il y avait un moyen assez facile de le faire. L'état de session fournit une fonctionnalité appelée Partitioning, où vous pouvez répartir votre état sur plusieurs serveurs SQL. Vous pouvez fournir une fonction pour sélectionner le serveur SQL en fonction de l'ID de session (SID). L'astuce est que vous pouvez utiliser cette fonctionnalité avec un seul serveur, juste pour choisir le serveur dynamiquement.

La configuration web.config ressemble:

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

La fonction qui choisit le serveur SQL ressemble:

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

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

Cette approche nous a permis de continuer à utiliser un web.config pour la production et le développement .

+1

+1 pour une solution géniale et simple. Fonctionne comme un charme – JOpuckman

1

Selon cet article, vous pouvez personnaliser le fournisseur d'état de session:

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

Les informations présentées ici pourraient être utilisés pour concevoir une session sensible à l'environnement fournisseur d'État qui pourrait sélectionner la chaîne de connexion basée sur une configuration dans le fichier .config ou une autre clé environnementale.

+0

Je devais réimplémenter le fournisseur d'état de session SQL? Ouch – Andomar

+0

Vous ne voudriez pas totalement le ré-implémenter. Vous souhaitez essayer de superposer un mécanisme de découverte de chaîne de connexion SQL personnalisé sur le fournisseur de sessions SQL existant. –

+0

Mais le fournisseur de session SQL existant utilise la chaîne de connexion de 'Web.config'. Alors, comment pourrais-je réutiliser ça? – Andomar

3

Comme mentionné ci-dessus, je pense que vous ne devriez pas avoir à la fois des chaînes de connexions dev et prod dans le web.config. Vous pouvez utiliser un projet de déploiement Web pour résoudre ce problème. Vous pouvez utiliser un projet de déploiement Web pour remplacer vos paramètres de configuration en fonction de la version. Par exemple, vous pouvez avoir deux fichiers de configuration externes nommés connectionStrings.dev.config et connectionStrings.prod.config. Si vous construisez dans Debug, il utilisera dev.config, mais si vous construisez dans Release, il utilisera prod.config.

Il est un peu différent de VS 08 et 10. Voici quelques références:

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

Questions connexes