We have an ASP.NET web site that uses SQL Server session state. The state is configured in Web.config
like:
<sessionState mode="SQLServer" sqlConnectionString="data source=TheServer;
User ID=TheUser;password=ThePassword;" cookieless="false" timeout="480"/>
But there are three environments (development / staging / production). All the other connection strings are configured like:
<configuration>
<connectionStrings>
<add name="Development_Db1" connectionString="..."/>
<add name="Production_Db1" connectionString="..."/>
</connectionStrings>
</configuration>
At runtime, we pick one to connect to the database based on hostname. Unfortunately, the Session State connection string appears to be hard coded in web.config
.
Is there a way to configure SQL Server session state at runtime, or make it refer to a connection string from the connectionStrings
section?
config or Web. config configuration file identified by the sessionState tag. When a new client begins interacting with a Web application, a session ID is issued and associated with all the subsequent requests from the same client during the time that the session is valid.
web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive. The sessionState element enables you to specify the following options: The mode in which the session will store data.
Session is a State Management Technique. A Session can store the value on the Server. It can support any type of object to be stored along with our own custom objects. A session is one of the best techniques for State Management because it stores the data as client-based.
As it turned out, there was a fairly easy way of doing this. Session State provides a feature called Partitioning, where you can spread your state over multiple SQL Servers. You can provide a function to select the SQL Server based on the session id (SID). The trick is that you can use this feature with ONE server, just to choose the server dynamically.
The web.config
configuration looks like:
<sessionState mode="SQLServer"
partitionResolverType="YourNamespace.PartitionResolver"
cookieless="false"
timeout="60" />
The function that chooses the SQL Server looks like:
public class PartitionResolver : IPartitionResolver
{
public void Initialize() {}
// The key is a SID (session identifier)
public String ResolvePartition(Object key)
{
return <grab your config here>;
}
}
This approach allowed us to continue using one web.config for both production and development.
As mentioned above, I think you should not have both dev and prod connections strings in the web.config. You can use a Web Deployment Project so solve that issue. You can use a web deployment project to replace your config settings based upon the build. For instance, you could have an two external config files called connectionStrings.dev.config and connectionStrings.prod.config. If you build in Debug, it would use the dev.config, but if you build in Release, it would use prod.config.
It's a little different from VS 08 and 10. Here are some references:
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With