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: WinFX, NETFX3, XBAP

Email this | Bookmark this