Ryan has posted a nice, consise write-up of getting started writing help in Longhorn.

Apparently Robert had a conversation with a customer that was holding up .NET adoption because Longhorn was coming with Avalon. If you’re already planning on building Longhorn-only applications, more power to you, but most folks will need to write apps that run on other versions of Windows for some time to come. For those folks, we have .NET and Windows Forms today and for at least another decade. Let’s do the math:

• According to recent industry rumor, Longhorn won’t ship ’til 2006.
• According to our internal OS folks, a new OS isn’t ubiquitous enough to target it as a base for new consumer application work for 6 years.
• Even 2 years after .NET was available everywhere, people are still actively doing the MFC and VB6 thing.
• 2 years ’til 2006 + 6 years ’til ubiquity + 2 years not doing the new thing = 10 years of good, strong life left in Windows Forms at least.

In spite of my love on Avalon, I’m so confidendent that Windows Forms has a life left that I’m working with Mike on Windows Forms Programming 2/e. A book is hard enough that you don’t do it if the topic is dead, so that’s me putting my time (and Addison-Wesley’s money) where my mouth is.

Robert Hess, that .NET Show guy, talks about why he’s so into Longhorn in the recent .NET Shows lately:

“What you -do- need to pay attention to, is how ‘Longhorn’ will evolve the users concept of exactly what a Windows application is all about, and what features and functionality it should be providing them with. Many application developers should be starting to think about this TODAY, and how to begin incorporating some of these features into their application moving forward. Just the schematized file system that WinFS will introduce alone can represent not only a big jump in the potential functionality of an application, but also a considerable change in how your existing application might want to begin thinking about data storage.”

Markus Mielke, a PM on the Avalon team, provides some performance tips on Avalon inheritable properties, centrally shared resources and property triggers.

Marc Clifton, a concerned 3rd party, provides thoughtful criticism of XAML.

Chris Anderson, Avalon Architect, takes Marc’s criticism and provides a thoughtful response.

Because of where we are in the Longhorn release cycle, i.e. a long way from a release, if the Avalon team agrees with Marc, they can make real changes.

As a result, Longhorn gets better because it’s able to accept early, critical feedback. Perfect.

Today, Joe Marini, a Microsoft PM on a project that dare not speak it’s name, posts a blog reader built entirely in XAML, i.e. no .NET code.

Last week, Chris Anderson, an Architect on the Avalon team, showed us that Avalon requires no XAML at all if you don’t want to use it.

However, closer to the truth are Don and ChrisAn, Longhorn architects, on using a mixture of XAML for declarative UI tasks and code for handling events.

My own preferred model is to do just as much as I can in XAML, because I find declarative style coding more flexible, but to put into code what makes sense, e.g. most event handling. My line in the sand is this: if I would have to embed code in the XAML, I go to real code, otherwise, I use XAML.

The tables are well and truly turned from when I interviewed Carl with Rory acting as color man to where Rory is hosting and I’m just there to fill a seat. The guest is Tony Bain, who is new to me, and the topic is SQL Server apps, which, while I'm familiar with the technology, hasn't been part of my production quality app work since embedded SQL was the rage (and I miss it!). Should be interesting at the very most. : )

Marc Clifton, author of the MyXaml open source project, publishes a series of articles exploring opportunities for improvement for the Avalon architects to consider:

• Is Microsoft Bollixing Up XAML?–a look at “tag names are class names”
• Is Microsoft Bollixing Up XAML? — The joys of VisualTree
• Is Microsoft Bollixing Up XAML? — The case of the missing collection
• Is Microsoft Bollixing Up XAML? — Decorating the house of cards

I only wish that he would post his thoughts of how XAML should look.