Windows Forms and Avalon

A lot of people have written on Windows Forms and Avalon, from Michael Harsh  and Joe Stegman on the Windows Forms team to the PDC docs, to Ian Griffiths. Based on all this, I realized that it's clear that, even though we at Microsoft think we're clear about when to use each, we haven't made it clear to customers. So I took the opportunity to write something up and have it reviewed by the Avalon and Windows Forms teams. What I found most interesting about this process was how hard it was to get to a simple, memorable set of guidelines (see the bulleted list below). The interactions of the software and requirements of each development project mean that there are choices to make. In any event, I'd love feedback if you have any.

At PDC2003, Microsoft introduced a new Windows presentation technology, code-named “Avalon.” Though Avalon v1.0 is not slated to be available to customers until 2006, we want to provide guidance on the relationship of Avalon to Windows Forms to ensure that customer investments in user interface are protected.


Windows Forms has substantial customer adoption today. It delivers a powerful rapid application development experience with full integration with Visual Studio, which lowers cost of development and time to market of smart client applications. Windows Forms v2.0 will release with Visual Studio 2005 (prior to Avalon v1.0) and is the best way today to create client applications using the .NET Framework. Going forward, Windows Forms will continue to be part of the .NET Framework and supported as such and is the main way to write managed code today to prepare for Avalon.


Avalon is Microsoft’s future presentation platform, designed for creating visually stunning, differentiated user experiences. Avalon builds on top of DirectX and introduces a unified engine for creating forms-based applications, graphics, video, and documents. Avalon’s engine fully exploits the richness of today’s hardware. When delivered, Avalon will become Microsoft’s strategic UI platform.


Microsoft is committed to providing guidance, tools, and technologies that will enable customers to leverage their skills and, where appropriate, source code to extend applications with the latest technologies. One of the key areas Microsoft has invested in is interoperability between Avalon and Windows Forms, enabling Windows Forms controls to be used in Avalon applications and Avalon controls to be used in Windows Forms applications. This interoperability technology will help customers smoothly transition to Avalon.


Microsoft’s roadmap for client UI development has three main phases:


  1. Today, use Windows Forms v1.1 and observe the Microsoft Patterns and Practices guidance for maintaining clean separation between UI and other application logic.
  2. When Avalon v1.0 releases (scheduled for mid-2006), we recommend that applications looking to differentiate their user interface such as Web sites and graphically intensive applications such as complex data visualization look closely at Avalon. Other applications should continue using Windows Forms.
  3. Following the release of Avalon 1.0, the next version of Visual Studio following Visual Studio 2005 will contain tools and designers to support Avalon. At this point, customers should start to move their new development efforts to Avalon and use the Windows Forms/Avalon interoperability features.

Comments (33)

  1. Hi John,

    your advice seems good and valid ,however, I think the problem is that the MS developer tools do not lead you in the direction of separating presentation from application code. A while ago I wrote a blog entry on this very subject

    Sadly the good developers will separate their code and then a lot of people will not and make a later move to Avalon problematic. I think the tools need to provide more guidance as a lot of people probably don’t even know the patterns site exists.

    Martin Spedding

  2. We’re working on making the tools better at providing inline guidance about this — VS 2005 in particular.

  3. Uwe Keim says:

    The former(?) MFC team should keep an eye on the separation auf UI and application code. I think their ideas were rather good, only the C++ language itself was not _that_ suitable for it…

  4. Jim Ley says:

    You’re recommending we use Avalon on web-sites and complex data-visualisations? Seen as using it on web-sites is obviously out (there will be too many legacy users to even consider the technology, even if you’re willing to say IE only) So it’s only worthwhile considering for complex-data-visualisation, I don’t do any of that, so presumably Avalon is completely irrelevant to me and I should put no effort into learning it?

  5. I love being baited! 🙂

    There are several scenarios on which you could use Avalon on a Web site. Already today there are full Windows applications that let sellers on eBay sell their equipment — customers gladly download an application to help with this. If you built a better application that used Avalon and was transparently downloaded from the eBay site (or one of the sites that has made a business out of enhancing eBay), you could have an easy-to-update application that looks great. Or if you’re a content provider like MSNBC you’ve already pushed the limits on what DHTML can do for your information, so you may want to build an application that lets you display it in a differentiated way.

    Yes, we’ll have to overcome the fact that Avalon will run on XP and Windows Server 2003 and Longhorn and that we’ll have to get it distributed. But that’s a simple matter — we’ve done over 100M desktops with the .NET Framework and can easily do that with Avalon.

    So yes, you should put effort into learning it. But if you’re only building simple forms-based intranet applications today, you may want to wait until Avalon is what everyone is using.

  6. Dean Harding says:

    That looks like great advice for Avalon, but what about Indigo? Should I still be using .NET remoting for my connected applications, or should I start looking into Indigo? I’m thinking here of internal Intranet-style apps where it’s no big deal to require Windows XP and a WinFX download or whatever…

  7. Joe Long did a presentation at PDC 2003 that talked about which technology to use. And Don Box is always blogging about this kind of thing at

  8. Jim Ley says:

    Thanks for clarifying that you don’t mean websites, but a particular kind of application that is web-deliverable/maintainable, the sort of thing we do today with <a href="">Zeepe</a&gt; or by embedding trident inside our own traditional wrapper, for web-sites we shouldn’t use anything other than traditional IE6 supported techs, or is there something else?

    I still don’t see "differentiation" as a particular goal for my web-deliverable applications, differentiation is only good for marketing/branding, and flash is much better for that – it just works. In applications I want consistency, I want users that will know how to use it and how it’ll work straight off the bat.

    Distribution is a big problem, there’s alternatives that run on all the platforms, not just XP/Longhorn (my customers don’t use Server for work…) and I’m sure the Service Pack 2 "not available to all" policy will continue, and whilst I can appreciate the sense of that – I still need to be able to sell to those people, my products are rarely sufficient for people to buy a new OS.

    My experience of the availability .NET frameworks haven’t been enough for me to just use it, it takes an awful lot of effort of to get sign-off on the use of .NET, and there needs to be a powerful business case (which basically has to revolve around existing products which we can re-use.)


  9. Fair enough points. From my perspective, one of the things that Avalon will do very well (along the lines of "differentiation") is to help meld the Web and Windows experiences the way Microsoft Money does today so users have an experience of your "Web site" that is local and customized to how you work. Is this a developer problem? Not really. But most of the companies I talk to from a business perspective are fighting for share of mind and share of clicks, and establishing a persistent desktop presence is part of that. Avalon makes that presence simpler.

  10. Jim Schmidt says:

    I’m currently a .net developer (among many languages and platforms). My fear with Avalon is that Microsoft is trying to remove the "internet" from the internet. What made the internet so popular is the interoperability between disparate platforms. If Avalon does not run on all clients, then companies wishing to deploy Avalon applications will be forced to deliver two (or more) completely separate applications to support the needs of their customers. Development costs being one of the highest expenditures, very few companies are going to be able to justify having two codebases. Instead, many will opt to trade some of Avalon’s super-human user-experience for a "write once, run anywhere" approach. There are many competing technologies, XUL, Flash MX, etc. I fully understand that Avalon vs. Flash MX is not even a battle from a technical standpoint. But from a business standpoint, the domain overlaps. Microsoft should know better than anybody that, between the technical aspects and the business aspects, the business side always wins. If MS tries to force a Windows only client on the user, they will be overlooked by businesses, whom seek only to reduce the bottom line, and Microsoft become a non-player in the computer world. Is this the goal of Avalon?

    IMO, one of the strengths of .net is the way Web Forms abstracts the client.

  11. John –

    the problem for many developers is that they really use quite a variety of different forms while developing in Windows tools:

    WebForms => ??

    InfoPathForms => ??

    VBAForms => ??

    classic HTML Forms => ??

    WinForms => all except complex visual forms and WebForms ???

    If you tell us the mappings I will post them on my site.

    Jacques Surveyer

  12. AEB says:

    I think MS Money is an excellent example for reference. I’m still impressed by how well it combines the best of both worlds.

  13. If you want something easy to deploy, use, as it has only a small dll to be copied to the client (no installation) and runs in restricted security contexts:

    The run-time is free, you don’t have to wait 2 years for a released version, and the vector graphics designer is integrated in Visual Studio .net.

  14. You might want to contact me directly through Mardi Brekke. But the question you’re asking is orthogonal to the point that this doc makes.

  15. Then keep using ASP.NET!! 🙂

  16. This is still one of the best examples of an online/offline application that I’ve ever seen. The Money guys really get it. I haven’t used the latest version of Quicken, but would be interested in how that’s using online/offline experiences as well.

  17. Byron Adams says:

    Sorry, it’s Chinese only, at this time, but this web is a good example of presentation, code, and data separation. All work is done after the initial load via XmlHttp and .Net web services. Email:

  18. Byron Adams says:

    Sorry, I forgot to mention that you can enter with the "guest" account and password "guest". It’s limited, but you can still get the feel of the UI.

  19. John –

    Orthogonal ?? I think not – it is elementary developmental.

    Microsoft shop is currently using VBA with Word, Access, Excel and ASP for numerous desktop and Intranet apps – hence the need for VBAForms, HTML forms, and WebForms. Their managers say it is a brutal change management exercise. So a consultant was hired to fix it up. She recommands consolidating around InfoPath, hence the new but not compatible InfoPathForms. The company is ready to bite when all the discussion on Longhorn breaks out and new Avalon forms – now the company is back to square one.

    Jacques Surveyer


    PS: Who and where is Mardi Brekke? I am at

  20. I’ll have Mardi ping you.

    But it’s different. When to choose Windows Forms vs. Avalon is one question to do with a particular (similar) type of application — once you’ve decided on a "smart client." InfoPath is for a different challenges — it’s more the logical successor to Access. And Web Forms is a different solution to a different problem. But they’re all for slightly different problems

  21. John –

    Now I am totally mesmerized. The decision flowchart seems to be:

    switch (wheretogo){

    case "today":

    call Winforms(1.1);


    case "mid 2006":

    if(ComplexGUI || WebApp) {

    call Avalon("looksee");

    } else call Winforms(1.1);


    case "when VisualStudio Avalon appears":

    if(adventurous ? wetbehindEars : savvy) {

    call Avalon("use");

    } else

    call Winforms("WinformsAvalon Bbridge");


    case "VBAForms":

    call HailMary("move upto VSA???");


    case "HTML Forms":

    call HailMary("shame on you!");


    case "WebForms":

    call Orthodontist("He will know what..");


    case "Infopath Forms":

    call Orthodontist("It is going to cost");



    call Winforms(1.1);


    This should parse in J++ but I am not sure all the routines are available.


  22. OK, this is hysterical.

  23. No, this is realistic I’am afraid.

    As much as I like the idea of reusing windows forms for websites and making websites more interactive

  24. That wasn’t quite the point I was trying to convey. Can you elaborate?

Skip to main content