Question:
How will ASP.NET handle session management?
Answer:
"ASP.NET does not rely on SQL Server or LDAP for session management. Basically we provide two new additional features:
1.) Cookieless Session: This is where we "munge" the sessionid into URLs as opposed to client-side cookies to keep track of SessionIDs (enabling you to now use session state even with browsers that have cookie support disabled). We automatically do the munging for you (no code changes required) to make this happen for both static and dynamic content (so you can link off to a static html page which then in turn links off to another dynamic page -- and the session is maintained).
2.) External Session State Support. This is where we store session values into an external state store instead of the ASP.NET worker process. This guaretees that state is stored accross worker process restarts (providing great reliability) as well as accross multiple machines (providing built-in web farm support). We ship support for two session stores out of the box: 1) the "ASP.NET state store" which is a dedicated NT Service that can run on any box -- and which ships with the ASP.NET bits. 2) support for storing session data directly into SQL Server. This later option is more scalable -- but does require you to buy SQL Server in order to make it work.
"Note that the above two state options are completely orthoganal from each other -- ie: you can use them together or separately. Also, our external state store support is pluggable -- meaning that we expect other third parties (as well as people like MS Commerce Server) to plug in their own store support into the model. "With regard to performance, we are *much* faster than than existing pre-ASP.NET state solutions when doing out of proc state. We are leveraging ASP.NET's new MTA based thread pool to do async read/write operations that enable us to avoid blocking worker threads when retrieving and updating the state (instead using iocompletions to reuse threads). This should improve system throughput significantly and was not possible before with ASP (since it used an STA thread pool and as such couldn't do async operations)."
Question:
Will there be any tools to port ASP applications to ASP.NET applications?
Answer:
"Our goal will be to have porting utilities available to help identify/update code in existing applications that needs to be modified in order to work with ASP.NET. "... ASP.NET will run side-by-side with existing ASP. As such, you will be able to incrementally move your apps forward at whatever time schedule you like. This -- combined with the porting utilities -- will hopefully make upgrading a non-painful process."
