Choose an existing technology Foo and imagine a newer, better way of doing the same thing called Bar that’s coming in some number of days/weeks/years. Sean and Scott say that you have the following choices:

A. Blissfully continue to use Foo.
B. Continue to use Foo, but research Bar, and architect for its use once it’s available.
C. Don’t touch Foo with a 10 foot pole. It’s dead after all. Touching it is probably illegal in 46 states.

Some folks hold onto option A too long, while some jump into option C too soon. The answer is almost always B within some delta of “it’s available” that’s appropriate for your business.

Sean and Scott call Foo and Bar “Windows Forms” and “Avalon,” but as they point out, these are the decisions we’re always making on new technologies. What’s the best judge of the delta around “it’s available” for adoption? That’s all about your specific business needs and don’t let peer pressure sway you either way.

Robert McLaws makes an interesting observation about the possibility of consuming XAML from a web server:

“So, if Microsoft wants to blur the lines between a web site and an client-side application, what makes you think that the next version of IIS will not support serving up XAML to the client. Instead of getting a limited browser experience at http://www.longhornblogs.com/default.aspx, what if you could get a super-interactive experience with the full power of the client at http://www.longhornblogs.com/default.xaml? What if, on a mobile device, you could use web services to allow location-aware applications ultra-dynamic, serving up XAML UI code along with data? A thick thin-client? Talk about a contradiction in terms. The possibilities become greatly expanded if you beging looking at what’s in front of you instead of looking behind your shoulder at what’s behind you.”

The future is unwritten.

Chris Anderson just did a fabulous job describing what makes Avalon more extensible than existing popular UI frameworks. What Avalon allows is the ability to have a Button instance like so:

<Window>
  <Button>Hello</Button>
<Window>

And then, somewhere else, using Styles, setting the VisualTree of what a Button looks like to be whatever you like, e.g.

<Style>
  <Button />
  <Style.VisualTree>
    <FlowPanel>
      <!-- anything you like in here,
e.g. <Text>, <Video>, <Rectangle>, whatever -->
      <ContentPresenter />
    </FlowPanel>
  </Style.VisualTree>
</Style>

Two interesting things about this button style. The first is that you can make a Button look however you want it to look, without worrying whether the Avalon team had that in mind up front. Two, when you want to drop in the content inside the Button tag, e.g. “Hello”, you drop in the ContentPresentor and it knows how to display what was placed in the Button (again, which could be anything). Simple and flexible: two things that I’m finding to be true more and more about Avalon the further I dig.

If you’re using Longhorn 4074 and MSBuild is telling you this, ‘The target “GetOutputAssembly” does not exist in the project.’, then try these steps to solve the problem:

• Backup %windows%\microsoft.net\windows\v6.0.4030\WindowsCommon.Target because you’re about to modify it

• In WindowsCommon.Target, replace all GetOutputAssembly with BuildOutputGroup

• Save and Close WindowsCommon.Target

• Re-run MSBuild and enjoy

“If you’re familiar with data binding in Windows Forms or ASP.NET, you ain’t seen nothin’ yet. In this presentation, Chris Sells, Content Strategist for the MSDN Longhorn Developer Center Web site, will cover data binding in Avalon, the new UI stack in Longhorn, Microsoft’s next OS. Chris will cover the basics of data binding and then move into transformers, filters and styling. If you’re going to build UIs in Avalon, you’d be crazy not to use data binding to do it.”

Data Binding in Avalon
6/24/2004, 6:30pm
Portland Community College Auditorium, Room 104
1626 SE Water Avenue
Portland, OR

Some quotes from Anders on Channel9:

“On of the things that we are trying to think about deeply in C# 3.0 is this big gap that I still see between general purpose languages and databases… Anyone who’s building an enterprise app is using both worlds… There’s certainly a lot of progress we can make by truly marrying these worlds… It’s nothing but mismatch. We gotta do away with that.”

Now that we’ve removed memory management from my code and between InitializeComponent and XAML, we’ve removed the need to write UI layout code, the next big chunk that gums up the works is data integration code. To have Anders thinking about how to extend C# 3.0 to mitigate this problem has me all a tingle!

Chris Anderson, Architect on the Avalon team, shows the first XAML "Hello, World" code and then describes two big “aha” moments to which XAML programmers can look forward. I've been to both of the moments that Chris describes and have had one more he doesn't mention: data binding in Avalon changes everything about how I build my UI.

Wesner Moise reports on a talk that Jeff Richter did on the .NET versioning story in the Longhorn time frame. Some interesting quotes:

• “a library could not easily be updated since the CLR looked for an exact version match. There was a complex way to solve this problem through policy files; however, even engineers at Microsoft found this approach too difficult.”
• “Microsoft has a new approach for Longhorn and Orcas (.NET v3.0), which divides assemblies into two categories, Platforms and Libraries.”
• “Most assemblies will or should be libraries. Microsoft discourages the use of platform assemblies.”
• “There are actually three types of platform assemblies: System-wide, process-wide, and app domain-wide.”
• “Longhorn will no longer support multiple CLRs. Every managed application will be forced to use the latest version of the CLR on the system.”
• “Whidbey is expected to include an Assembly attribute, AssemblyFlagsAttribute, which allows to developer to specify Library, AppDomainPlatform, ProcessPlatform, SystemPlatform, or Legacy to identify the versioning scheme the CLR uses to load a reference assembly.”

I know that the existing versioning story doesn’t cut it for a lot of folks. Will this new model solve the problems? Is there a complexity danger?

Also, Ian has some thoughts on the new model.