Following
this post, I found it necessary to study more in detail the session management in ASP.NET web service applications. For quite some time I was very puzzled, because even the simpler tests would fail miserably, and a different SessionID would be returned on every call. In order to solve that problem, I got back to the roots.
First, I developed a ASP.NET 1.1 web service, and tested a web method in a web browser, using the asmx URL. This returns a test page with useful information about the service, and if your application runs on localhost, you can even invoke the web methods. This is very handy, because it allows testing the server side code without writing a client. My findings puzzled me even more, however, because everything worked as planned on ASP.NET 1.1 (i.e. the SessionID was always the same in a given instance of the browser), and failed in ASP.NET 2.0 (i.e. the SessionID was different on every call).
Obviously, the problem was on the server. I then decided to "take my head out of the hole" and to discuss this with a colleague. Sometimes the best way to solve a technical problem is to explain it to someone else. This helps taking a few step backs, reconsidering the issue, and often helps a lot. It certainly did this time.
My colleague asked me if a new Session was started on every web service call in the ASP.NET 2.0 application. I told him that I thought so (since the ID was different on every call), but to be sure, I wanted to add a breakpoint in the Global.asax "Session_Start" event handler. Well guess what, there was no Global.asax! OK, let's just add one (Add new item / Global Application Class). Then add the Session_Start event handler to it.
protected void Session_Start( object sender, EventArgs e )
{
Trace.WriteLine( "Session_Start" );
}
This allows placing a breakpoint and checking when exactly a Session is started. And here, to our surprise, the application started to work as planned! The same SessionID was returned on every call.
Conclusion
-
ASP.NET 2.0 doesn't add Global.asax to web service applications by default. This is different from ASP.NET 1.1, where Global.asax is always added when you create a new web service application.
-
When Global.asax is missing, a different SessionID is returned on every call, whatever the client does.
-
When Global.asax is added, everything works fine.
A quick test on ASP.NET 1.1 demonstrates this: Try deleting the Global.asax in a working web service application: the same symptoms can be observed, and a different SessionID is returned on every call. Once this was corrected in my web service application, every client started to behave like I wanted, success!