ASP.NET Changing Session ID's for each request

I ran into an issue where ASP.NET was changing the Session.SessionId for every request from the same user. A quick Google search revealed 2.3 million pages. I'll summarize one of the main reasons this can happen, and discuss 2 ways to fix it.


I've been working on a search function for a website I'm working on. We're taking the Lean software approach and implementing an extremely basic search for now. We're going to track the searches that users are making, and will have the data we'll need to make a better search in the next version.

In order to know if users are making multiple searches, we're storing the ASP.NET session ID with the search record in the database. Much to my dismay, every search request resulted in a different value in Session.SessionId.

The problem lies in the fact that ASP.NET is trying to be extremely efficient storing sessions for users. If ASP.NET doesn't have a reason to remember who you are, it won't. If you think about it, that can save a tremendous amount of work by avoiding session management.

If you want to tell ASP.NET that you want it to track user sessions, you can do one of 2 things:

  1. Store something in the session. If you store something in the users session, ASP.NET will be forced to associate that data with your current visit. Example code: Session["foo"] = "bar";
  2. Simply by handling the Session_Start event in your Global.asax. The presence of this method will tell ASP.NET to track sessions, even if there is no data in the session.

    public void Session_Start(object sender, EventArgs e) { }

Like this post? Please share it!

See a mistake? Edit this post!

How to get the best customer service for free

Today's tip is a hack for getting awesome tech support from a company for a product that you may or may not have purchased. It may not be polite, but it may be a method of last resort.


We all knows what happens if you buy a product and then call for support. If you're lucky, you get put on hold. If you're unlucky, you've called outside of their business hours of 1am to 3am. When you do talk to someone, you're treated like an idiot (in their defense, it's a learned behavior).

If you want great service, call their sales department. Tell them you're evaluating their product, but ran into an issue. You'll be talking to someone that actually wants your business. They're typically very helpful, and remind us of the benefit of good customer service.

Just today a coworker sent me a link (unrelated site) that had a link to a page called "Pre-Sales Questions". They're openly distinguishing between potential customers, and paying customers. The problem is that they make the pre-sales question form easy to use, but the paying customer form is not. Customer service is in a bad state.

My official recommendation is to to fully try out their product during a trial, so that when do you do talk to their sales team, they can at least earn a sale from it. Like I said, this is a method of last resort.

Like this post? Please share it!

See a mistake? Edit this post!

Programming for someone with blinders

One of your goals as a developer should be to make your code as readable as possible, both for yourself, and for the other developers you work with.

Horse with Blinders

One great way to determine if your code is well written, is to ask yourself if the code you're writing is readable by itself. Another developer should be able to jump into a module, and have a fairly easy time seeing what's going on. They shouldn't have to sift through thousands of lines of interweaved code to figure out what's going on.

Of course, what I'm talking about is simply a test for the single responsibility principle. If you've written a huge "do it all" class with thousands of lines of code, you're ensuring that you're the only one that will be able to maintain it. That that type of code usually suffers from high coupling#Low_coupling) to the other modules in the program.

I used to organize code into classes based on the type of functionality being provided. I used them more as containers for related functionality. At the time, I didn't see a reason to split it apart. I was very wrong.

In a recent article by Jimmy Bogard, he walks through creating classes with a separation of concerns. In the conclusion is my favorite part:

Now we have many more classes (4 vs. 1) and interfaces (3 vs. 0). For those who don't like more classes, GET OVER IT.

That is an excellent point. Why should you be afraid of creating more classes and interfaces? It's really not more code to write, in fact, it's often less. Refactoring tools remove many of the obstacles of maintaining the interface, class, and method structure

When someone looks at your code and you have 4 classes instead of 1, and those classes are very specific and short enough to process by our tiny brains, it will be much easier to maintain and modify (or even better, extend).

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG