Even a chimp can write code

Monday, November 27, 2006

RE: What I Hate About XBAPs

In his post titled What I hate about XBAPs, Charles Petzold rips me a new one. Among other things, my team owns the packaging and deployment mechanism for XBAPs. I think Charles is right on some counts but not all. In this post, I’m aiming to address his concerns as well as highlight some other factors that influenced our design and implementation. At the outset though, I must thank Charles for blogging about his concerns with XBAPs. My team and I appreciate the feedback and solicit this kind of feedback. If you "hate" anything in WPF, we’d like to know so we can look at rectifying the pain points.

Scenarios have their own pecking orders
Let me begin with the clichéd but true "we operate in a world with limited time and resources". Sending XBAPs via email and launching attachments wasn’t a Priority 0 scenario for the first-generation Windows Presentation Foundation offering. I would go as far as saying it wasn’t a priority 1 which sums up the nice-to-haves. And in this world too, natural selection is judge and jury.

I look at XBAPs as browser-hosted WPF applications that operate in a security sandbox. Apropos, then, the word "application": how many times a day do you get applications as attachments in your email? Not images or documents, mind you, but applications. In comparison, how many times do you navigate to content from within your browser, oblivious of the file extension or type being launched, but expecting it to launch in the browser. No, I’m not trying to present a (false) dichotomy. These are real considerations we have to weigh when we plan features.

Feature prioritization factors in a number of things, most importantly, customer feedback on how critical the scenario is to their application/business goals and end-user experience. Consequently it is not fruitful to architect XBAPs around scenarios our customers do not care about. Consider a couple examples of several such scenarios that heavily influenced our current design:
  • Tuppy Glossop authors an XBAP and publishes it to a network share or web server. Consumers access the XBAP via the browser by clicking on a hyperlink. Each time someone launches the XBAP, they see the latest version of the application published by Tuppy.

  • Bingo Little is an ISV who authors XBAPs for corporations who in turn host it on their own servers with their branding. They do this by updating the non-executable contents of the app, (resigning the manifests) and propping the application files to their web servers.

XBAPs do not exist in a vacuum
We’ve attempted to offer a broad set of options as far the application and content models in WPF go. It spans un-compiled XAML files to XPS documents to XBAPs to Standalone applications, with control flavors and inter-op sprinkled in between. The former two are best suited for being sent as email attachments. I try to resist the temptation of making XBAPs everything for everyone.

Launching EXEs is so 1990s!
As Charles correctly points out, email programs and corporate policies may prohibit launching EXE attachments. For this reason, .NET Framework deployment (specifically ClickOnce) provides the MapFileExtensions project property. When set to true, the built application’s executables and binaries have the extension ".deploy" appended to the actual file extension (.exe or .dll). This gives you another benefit of configuring only one blanket MIME content type mapping .deploy to application/octet-stream (which is the default on many web servers anyway). You can send people attachments that have a .xbap, a .exe.deploy and a .exe.manifest. In the same vein, you can deploy these files on a web server. When the .xbap is launched, the .NET Framework 3.0 deployment mechanism will recognize the other files.

Customer feedback influences future course
The WPF team does not understand your business or your customers. In fact you understand those best. And we work hard to understand you and your needs. If you, our customers tell us you really do care about scenarios that involve sharing WPF content via email, we focus on delivering that solution in the best way and timeframe possible.

However, I don’t believe the implementation matters so much. For instance, I can see this specific sharing scenario as being fulfilled by un-compiled XAML + code. That code can be inline or a referenced file. It can be script or C#/VB. This is all open to debate and the merits of any proposed implementation would dictate our approach. Right now, I’m taking Charles’s post as customer feedback on this scenario and am logging a work item in the product database to consider a solution. Needless to say, this feature is prioritized against the numerous others that are currently on the team’s radar, and is subject to feedback from other customers and partners. But I am confident that we can work out a good solution in a future version.

Tags: , ,

Email this | Bookmark this


  • I've spent many years working with Delphi where programs are generally compiled into a single self-contained EXE file. I can tell you that there are lots of small benefits from that sort of simple deployment scenario. I agree with Petzold that having XBAP's consolidated into a single file would be a "good thing". Please consider it!

    By Anonymous Scott Bussinger, at November 28, 2006 at 8:08 AM  

  • I'd suggest looking at the OS X bundle format, which they also use with their desktop widgets (to the normal user it appears to be an executable icon, but it is in fact a folder containing the executable, resource files, images, etc).

    By Blogger JulesLt, at November 30, 2006 at 4:24 AM  

  • I can't begin to tell you how many times i'm tired of people sending me .SWF extensions in the mail....

    Wait they don't....

    Point: I agree with you, its a "nice-to-have" ;)

    By Anonymous Scott Barnes, at March 9, 2007 at 7:40 PM  

  • I have a problem with the inability to send XBAP by email as well. Ever since I saw an early MS video presentation on the capabilities of Vista I have longed for this feature. I don't think that this is a "nice-to-have" feature; in fact I think it an integral tool to the WPF arsenal, and Microsoft's integrated computing philosophy.

    By Anonymous Martin Hinshelwood.com, at March 24, 2007 at 2:16 PM  

  • I recently started looking at WPF Browser Application and watched few good webcasts and no one talked about deployment scenario of XBAP applications. I think we need a presentation/tutorial type of video on deployment patterns of XBAP.

    By Anonymous Shaurav Pandey, at July 18, 2007 at 8:51 AM  

  • Ashish,

    There is a very real scenario that requires XBAPs to be hosted in Outlook (sourced from an attachment). Namely, it makes no sense to jump through the InfoPath hoops and MOSS Forms Server when XAML was specfically designed as the champion on Windows platform UI development going forward.

    Every scenario that today, requires InfoPath, should be replaced tomorrow with XBAPs. I want to be able to deliver actionable forms to email clients that users can take care of IN the client. Take timesheets for example. I want to email an XBAP to the email client with a reminder and allow the user to take care of the timesheet in the Outlook client instead of having to jump to a second system.

    It seems to me that supporting XBAPs as email attachments is a key scenario. Just because you aren't developing with it today (i.e. SWF argument), doesn't mean that it's not the better solution than to force the user to click a link and jump to a web page to complete a task; the user should receive notification of the task and be able to complete it in the same client...it's only logical and it seems like it's a fairly common scenario that most people today either ignore (force the user to click a link and complete the task in a secondary system) or are forced to use a dead end, wayward technology like InfoPath.

    Like Petzgold, I agree that the packaging and runtime are core requirements that need to be addressed for XBAPs to introduce some truly unique and powerful usage scenarios (like dynamic, actionable items in email - a very powerful concept).

    By Anonymous Charles Chen, at October 2, 2007 at 8:14 AM  

Post a Comment | Home | Inference: my personal blog