XBAP usage and maturity issues

Question

we're considering migrating our UI to XBAP. we've chosen XBAP despite knowing the clients must have .net pre-installed, since we're not targeting the masses but rather IT professionals in the corporate environment, and it's a way to preserve our investment (in a WPF based UI in a client-server architecture) and enjoy web deployment. however, we are concerned about the maturity of the platform/architecture and it's adoption.

do you know of any commercial applications out there using XBAP, and do you have any experience using it? can you elaborate on that experience?

also, as @Murph suggested, can you think of strong reasons to prefer clickOnce over XBAP (or the other way around)?

Answer 1

I could be wrong, but IIRC XBAP uses ClickOnce as it's underlying deployment method. [Cant find where I read this, so take that with a grain of salt.]

That said, I've had great success running a WPF application via ClickOnce deployment. As was stated before, you deploy all the files to your web server. As you release updates you simply copy them to your web server, as clients run the app they get prompted to update to the newest verison, you can require update, or allow them to deferr.

Its very user friendly and doesn't require the overhead of a browser to run your application.

Answer 2

I've been doing an XBAP tool, also for internal corporate needs. It's pretty easy to rollout updates -- just update the server app version and the clients will be updated next time they connect. So, in this aspect its not very different from ClickOnce.

The main problem for us was the "partial trust" mode, that you have to obey. And it goes wrong in some very unexpected situations, like for example, some of our third-party WPF failed because they used WPF bitmap effects, which in turn used GPU shaders, which was considered as a security violation by the system and blocked. I'm not sure if that kind of problem is solved in ClickOnce. The rumors are the XBAP trust mode will be less paranoid in .NET 4.

Otherwise, I don't see any difference. At least the development of XBAP vs stand-alone WPF is all the same. (Note: Silverlight is different, it uses only a subset of .NET framework, which is separately installed and available for several platforms. XBAP requires Windows platform and .NET Framework 3+).

Answer 3

We've had much success with ClickOnce, including production rollout to external, non-technical customers. It was easy to use, including being easy to integrate into our automated build process. Our experience is at least one more datapoint for you to consider in weighing the risks of the 2 alternatives.

You're right that adoption for XBAP is, indeed, very low. I think that's primarily because Silverlight makes so much more sense for most people who want the benefits of WPF/DotNet in a browser (since their apps can be cross platform with Silverlight).

Answer 4

Here's a fun fact. In .NET 4.0, they have added the ability for XBAP applications deployed via ClickOnce to run in full trust. No more partial trust required. That should give you some options!

Answer 5

We develop an application that has both a desktop and a web implementation. Because the functionality is almost the same we want a single source solution. The application is a project and drawing management tool for a CAD application. Most important reason to have it run in a browser is that the application will be used as a collaboration tool to exchange project data and drawings.

The problem with browser hosted applications is that they run in the browser and are thus limited to the rules that apply (as mentioned in another reply eg. new windows and trust limitations).

Because our application is mainly used in controlled intranets and extranets we think we can manage with our solution. Our application runs in full trust and is signed with our own certificate which makes life a little easier.

The benefits are of course the click once installation (and update maintenance) and the ability to let users install the application 'anywhere' (or course you need .NET and the certificate on our case) via a web site.

The biggest problems we faced were related to trust, navigation and dialogs which we could solve. Another problem is that our application uses web services to access data. The binding between a client and the web service is quite hard by default (embedded) but we also found ways to overcome this.

We can also run our application outside the browser (but install it via the browser). But our product owner currently wants the browser experience as this makes more sense to users. If you install via a web site but run the application outside the browser then the limitations that the browser demands are less.