views:

124

answers:

3

I wanted to know if it was possible to keep the Session variable thought builds in a ASP.NET + C#?

I ask this because every time I make a minor change to my application and need to rebuild it, I need to login again and do a nunch of operation after that... it's taking a lot of my time.

If there is no way around I can set up a testing mode where I'll always be logged in, or automatize the log in procedure... but it would save me time to just keep the Session after a build.

+6  A: 

You could change your test server to use the State Server or SQL Server session state modes, which will survive an application restart.

Jon Galloway
is there a way to define it so that it uses the default sql server? what are the drawbacks of doing this?
marcgg
Yup. I tend to use SQL Server, but both types of configurations retain their sessions are retained through app restarts. I would say that, to the unexperienced person, SQL Server is probably the easiest way to set up this configuration.
Dan Atkinson
I'm a bit confused, should I just go <sessionState mode="SQLServer" sqlConnectionString="Integrated Security=SSPI;" /> ? Do I need to specify the server as such: <sessionState mode="SQLServer" sqlConnectionString="Integrated Security=SSPI;data source=SampleSqlServer;" />?
marcgg
You can configure which SQL database is used to store the session state: http://support.microsoft.com/kb/836680
Jon Galloway
I would recommend using a separate session database so you're not messing with your application database. There's more info on the setup here: http://idunno.org/articles/277.aspx
Jon Galloway
Apparently I need to install something: "Unable to use SQL Server because ASP.NET version 2.0 Session State is not installed on the SQL server. Please install ASP.NET Session State SQL Server version 2.0 or above. ". Do I really need to or did I do something wrong?
marcgg
did you run aspnet_regsql.exe? - http://msdn.microsoft.com/en-us/library/x28wfk74.aspx
Dan Atkinson
oh, no. I'll do that right now.
marcgg
It looks like I don't have aspnet_regsql.exe in the folder they specify. I feel like this might be overkill for what I'm trying to obtain since it might also lead to trouble when deploying the application...
marcgg
If it's not there, I would install .NET on your db server (although, I'm surprised that it's not already there).
Dan Atkinson
You can run it from another machine, I believe. I haven't done it for several months though, so I'm not 100% positive.
Dan Atkinson
+2  A: 

I have used this hack when I didn't want to deal with authentication during development:

protected void Page_PreInit(object sender, EventArgs e)
    {
        // Fake authentication so I don't have to create a damn Login page just for this.
        System.Web.Security.FormsIdentity id = new FormsIdentity(new FormsAuthenticationTicket("dok", false, 30));
        string[] roles = { "a" };
        HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
    }

This is only going to work on the page you put it on, though you could add it to a base page.

You definitely have to remember to remove this before you promote the code to test/QA/UAT/prod!

DOK
Or, if you have split config files for dev and live environments, you could just read an applicationsetting (say InLiveMode) and wrap the whole thing in an if statement.
Dan Atkinson
Thanks, but I'm not a big fan of this solution... It might hide some bugs or break some stuff. It also makes pushing something live more annoying
marcgg
With Dan's comment it might be interesting actually
marcgg
It's still a bit hacky, but yeah, the web.config AppSettings thing mitigates a lot of the risk involved.
Dan Atkinson
If you're concerned about this creeping into deployment, keep it in dev by wrapping it in #if DEBUG <code> #endif. Then, you just have to remember not to deploy in debug mode, which you definitely should not be doing anyway.
DOK
I agree it's hacky, but then we are trying to circumvent authentication. One advantage of my approach was that the app I was working on was using roles, so I needed to add them, too, to get the necessary user permissions. You can also add other user data here that would come from the normal authentication process. Authentication can be SO annoying during development.
DOK
This is true. I prefer the config method more because it can somewhat declutter your code with debug code (especially if you create a strongly typed appsettings facade class). Also, using Web Deployment projects would help prevent the possibility of forgetting to switch off debug symbols before building.
Dan Atkinson
what do you call "the config method" ?
marcgg
hmm... I'll write a answer for it, but set it as Community Wiki as it is effectively a rework of DOK's answer. If you prefer it, please upvote their answer.
Dan Atkinson
A: 

This answer is community wiki so as not to generate any reputation, as it's effectively a reworking of DOK's answer. If you like it, please upvote DOK's answer.

@Dok, if you want to edit your answer to incorporate any of this, please do, and I'll gladly delete this answer. :)

DOK, as mentioned in my comments to your answer (and possibly some help for your own solution), you might want to do the following:

#if DEBUG //As mentioned by DOK in the comments. If you set debug to false when building for deployment, the code in here will not be compiled.
protected void Page_PreInit(object sender, EventArgs e)
{
  bool inDevMode = false;
  inDevMode = bool.Parse(ConfigurationManager.AppSettings["InDevMode"]); //Or you could use TryParse

  if(inDevMode)
  {
    // Fake authentication so I don't have to create a damn Login page just for this.
    System.Web.Security.FormsIdentity id = new FormsIdentity(new FormsAuthenticationTicket("dok", false, 30));
    string[] roles = { "a" };
    HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
  }
}
#endif

To further ensure that you do not accidentally deploy with this active, then you would have your app settings in seperate config files (as well as your debug section). If you use Web Deployment projects, then you can put your dev config settings in one file, and your live config files in another (this is usually dev.config and live.config!).

eg, in your web.config:

<appSettings file="dev.config"/>

In your dev.config:

<appSettings>
  <add key="InDevMode" value="true" />
</appSettings>

In your live.config:

<appSettings>
  <add key="InDevMode" value="false" />
</appSettings>
Dan Atkinson
how good is it to put this in a class derived from Page class? so preventing writing this snippet to every page class?
ercu
Well, it doesn't have to be there. It could be in the Session_Start, but I was simply following on from DOK's answer.
Dan Atkinson
sounds good. Please also take a look at Jon's answer that is interesting as well.
marcgg
Marc, please can you set DOK's answer as the right one? I didn't really add a lot to this answer that isn't ripped off from hers. Plus I don't get any extra reputation for this one. :)
Dan Atkinson
Also, this doesn't really answer the question, as it simply creates a new session for you, rather than Jon's solution of putting it in SQL Server or State Server! :)
Dan Atkinson