As you'd expect from Microsoft there is lots of good information online, and it makes for interesting reading. Unfortunately it is presented with the usual breathless wonder at the daring of Microsoft to go out on a limb and provide us with the very latest and greatest technologies:
“Use the .NET Framework 3.0 to build applications that have visually compelling user experiences, seamless communication across technology boundaries, the ability to support a wide range of business processes, and an easier way to manage your personal information online.”All of that is available without .NET Framework 3.0, but I guess it was better than saying:
“Use the .NET Framework 3.0 to build applications where you actually have to provide what the designers want, that use Google/Yahoo accounts, play nice with SOA and have a consistent way to implement the workflow that makes up 0.5% of your application.”Sarcasm aside (marketing is probably doing their best), the extra bits are well worth having. Well, okay, CardSpaces may become the next .NET Passport (remember how popular that was!?) but the rest of the package looks genuinely useful.
Windows Presentation Foundation (WPF)
I have my doubts about how Agile WPF will let a team be, I mean it's great when you mix designers into the development team, but I feel it may allow too much 'frozen design' at the start of a project, with the expensive designers being expected to hand across their tidy XAML code to the developers who are expected to not deviate one iota from it. However it may be less relevant to cross-browser websites anyway, as from what I've seen (and here) it is aimed fairly squarely at thick-clients, and the ActiveX control for WPF/E makes it fundamentally not cross-browser friendly.
[UPDATE: Here is a great blog post about why designers should be involved in development.]
Windows Workflow Foundation (WF)
I first got interested in workflow-enabling applications back in 1994 and have found it easiest to create them in Lotus Notes and SharePoint/InfoPath. However my resume is not littered with dozens of successful workflow projects. Why is that? The main reason is that workflow is usually a small subset of any business problem, and the meat of the issue is within each task. The exception is when the task is simply data capture, or is executed in an existing legacy system that needs to be more closely integrated with others to enable more efficient workflows. In the first case, WF is overkill (and may have significant performance gotchas), in the second it offers a genuine solution (especially in conjunction with WCF). So I'm interested, but I don't think I'll be wrapping every application I create in workflow just because WF exists.
Windows Communication Foundation WCF)
This looks genuinely interesting, an easy way to implement SOA within .NET, and of course extensive support of SOAP. More interesting (IMHO) is that it also supports Representational State Transfer (REST) and can be extended to support ATOM (for RSS) and JSON (for lightweight AJAX) formats. I previously mentioned how I was re-doing the Agile Web Development with Rails tutorials as a way of getting a better handle on REST, and mentioned a great slideshow on RESTful development(see 3rd slideshow at bottom of post). I can think of a couple of ways we could use this right away, but the exciting bit is really to think through REST and consider whether it adds value to our application design (or not).
Lastly, Scott Guthrie has a great post up about how Visual Studio 2008 will support nested master pages giving us WYSIWYG support, and (even better) we can do all this with .NET Framework 2.0, without needing to go to .NET Framework 3.5 (yay!). I've been acquainting myself with master pages in ASP.NET 2.0, somehow all the projects I've worked on in the past have managed not to use this feature, then again most of my ASP.NET projects were 1.0/1.1.