If your application is relatively small and simple, ClickOnce is great. Basically, one (maybe two or three) project in the solution, compile size relatively small (to handle slow connections if necessary).
The problems start to arise when your solution starts to get complex. Multiple projects, with references in XAML crossing the projects, and it gets a bit tricky. Stuff that works fine in Visual Studio tends to not work once deployed through ClickOnce, unless you are very careful in your reference definitions. It only takes one misdefined definition, and the whole thing can break--and the error messages received will likely be too generic to easily find it.
So with a complex application, ClickOnce becomes completely unfeasible. In my opinion, it's a piece of crap, unless you keep your application small and simple--then it's great.
I use it on my small and simple applications as it offers easy deployment.
But on the one complex application I support, originally it was deployed as ClickOnce, but at some point the ClickOnce deployment broke, probably due to an incorrectly defined reference. The application worked fine in Visual Studio, or when installed using WiX. But it would go so far in ClickOnce, then blow up, and I never could figure out what ClickOnce didn't like.
So it was easier to give up on ClickOnce and switch to installing with WiX and use our own home-grown mechanism for updating the application. That home-grown mechanism had its own set of problems, but at least it was under our control.
As a final note: WiX is great. Being driven by XML allowed automatic update of the project definition through Team Systems Build. If I get around to it, I might post the recipe for this. Leave a comment if this recipe would be valuable to you (to encourage me to post it sooner).
No comments:
Post a Comment