Junfeng has posted a great list of NET 2.0 highlights that is definitely worth a read.
I think I’m not alone in maintaining lists of things that would have been great to have while tackling former problems. In my case, those happen to mainly be Java apps, but regardless of the framework, they’re nice to have now. Some are catch-up, of course, like gzip support, or Edit and Continue being exposed by the CLR (VB.NET is the only language supporting it at the moment, of course – for those of you who use C# and would like to see Edit and Continue in a future release, you can weigh in with your opinion here: http://lab.msdn.microsoft.com/productfeedback/viewFeedback.aspx?feedbackid=bbbf7d31-204c-4a93-af08-fb80328fbe86). But, of course, like the Tiger/Longhorn debate I’m not sure how it matters who gets what first (a debate I don’t really get – Longhorn drops have been going on for well over half a year before Tiger previewed, and obviously Longhorn dev has been going on far longer, but anyway, I digress) nearly as much as it matters that ISV’s get the tools they need to stop writing so much plumbing code themselves. Some phrase it as “write to the highest level API possible“, others say “write as close as possible to your problem domain“ – in either case, ISV’s should write code that implements what is usually considered “business logic“ – any other code is plumbing that I hated writing in the past and I hate that ISV’s still have to write today. </soapbox>
Also, while developing Hatteras many of these make life tons easier/simpler.
- Direct ACL read/modify support
- Authenticated Streams
- Console Class Additions
- Data Protection API
- Edit and Continue
- Detecting changes in Network Connectivity
- FTP Support
- X.509 Cert store support
- NetworkInformation, Ping, HttpListener, custom caching behavior – I can simply not overstate how much easier our ISV life at Porivo would have been with access to these in the framework. It boggles the mind.
- Serial I/O support – mainly for some device control projects in my IBM past
- The BinaryFormatter class now supports version-tolerant serialization, which allows a type to be deserialized from the serialization of a different version.
Seriously, though, as Junfeng says, there’s obviously tons more, I just thought I’d provide highlights of his highlights 🙂
Oh, and totally unrelated, but Rory is joining – very cool 🙂