I've been giving some more thought to the ViewState stuff I mentioned earlier. It actually brings up something which I find most annoying about ASP.NET - and this is not a political point! Why exactly can't 'ordinary' users see the source for ASP.NET, so far as I'm aware, no equivalent of Rotor exists for ASP.NET. I'm guessing that certain MVPs can access this source though the Shared Source initiative - the rest of us have to rely on things like Reflector to poke around (imagine how useful it would be to be able to attach a debugger to the ASP.NET source!). The argument which I guess may apply to this would be the old 'if we give access to the source we can't change it' or 'people will change it themselves, causing us more problems' - umm, JSP and J2EE have full source access, and always have had - this just hasn't happened (though I did learn JSP far more quickly because I could root about and understand what was going on). So, assuming we can never access ASP.NET source, how do we get over problems lke I've been having messing about with ViewState? Simple, factory methods for core framework items. Luckily ASP.NET 2.0 does this for some items (mainly the new ones it has to be said) like Personalisation and Membership - where you can specify your own provider classes for these items. If only this were also the case for all the other ASP.NET core items - for example, Session state has a similar issue, you can persist to the three state stores which ASP.NET allows, SQL server, extrenal state server of In Process - would it have been really so difficult to allow the specification of a user-defined class for this as well (if ASP.NET 2.0 has this already and I'm just to dumb to find the reference, please let me know!)? So, ASP.NET 2.0 - big step forward in user customisation of core framework items - but just a bit further would be fantastic!

UPDATE: Just noticed this entry on Jason Salas's weblog - a ViewState API...hmm...not sure about how practical a declarative strong typing system would be (example 2); a site will generally store hundreds of items in ViewState - strongly typing each one would be a total pain. Example 3 is pretty cool though:

CHEESY EXAMPLE 3:

int homePhoneJenny = 8675309;

ViewState.Insert(“keyPhone”, homePhoneJenny,System.Int32);

That seems pretty useful!, so I could do ViewState.keyPhone to get an Int32 back...still doesn't solve the issue that we can't play with how ViewState works though - so I can't specify that I want to use Rijndael as the encryption mechanism (3DES is pretty slow!) or that I want to compress the ViewState / even store it elsewhere / modify how controls can access ViewState without all the playing with overloaded methods or even reflection (shudder)...