Being Pushy with VSTO ClickOnce
The other day I was in a meeting and it was mentioned that the new VSTO Deployment model didn't really support a "push" model. I've thought about this for a while and I have to disagree and agree. In software development "supporting" is really more of a Grey scale of difficulty. With enough effort any developer could reverse engineer something enough to replace, alter or extend any piece of software. It comes down to what degree of difficulty are you willing to go through (and how many assets you can use to implement something).
So today I'm going to talk about how a crafty developer may implement a push model with ClickOnce. So lets get pushy:
First of all, a quick blurb about what a "push model" is: the basic idea is is that the central server pushes installation/updates out to a network of clients. In a simple push model we ignore factors such as offline status and assume all clients are always connected.
So we'll begin with the easiest "fakey" push model, Forced Update Checking.
How it's done: Set 'update interval' to 'always'
Advantages:
Because we're just sticking with "vanilla" VSTO ClickOnce here, it's very easy to change to a different update frequency, there is still a lot of flexibility to change the model in the future. Don't incur a large usage bubble by having all machines getting the bits at the same time. Offline status can be ignored, ClickOnce supports Offline running out of the box. It's super easy.
Disadvantages:
The performance implication of always checking for updates may not be appropriate to the solution (slower deployment servers, slower network connections or simply being unable to reach the server frequently can negatively impact load times). There is no way to enforce a non-working status if the solution can't check for updates (VSTO doesn't currently support the 'online only' style of ClickOnce deployment).
The next closest technique is sms enforced updating without update checking.
How it's done: Set 'update interval' to 'never' and use SMS to enforce an update installation via VSTO Installer.
Assumptions:
Obviously SMS access to all client machines is necessary, but also the administrator should ensure that all machines within the network have the prerequisites before forcing them to attempt installing the customization.
Advantages:
Reduced performance impact in between updates (because updates are set to never the clients don't incur the security and update check "penalty" at application startup). Allows for resource management (only pushing updates during off hours for example). Still relatively simple to implement (given availability of SMS control).
Disadvantages:
Large bubble of activity could potentially cause issues (high network traffic may cause errors if the the connection for individual clients degrades too much). Requires SMS (for smaller networks this may be overkill). May not be possible to enforce updates (if a machine can be taken offline such that SMS cannot guarantee it gets the update command).
My final idea for creating a push system involves creating an update enforcer.
How it's done: Set 'update interval' to 'never' and build/install a service to enforce update installation via VSTO Installer. The basic idea is that the enforcer service would either listen on a port or check occasionally for updates. Ideally in both cases updates would be delayed on the client machine if the customized application is actually currently running. It would be possible to disable any non-updated customizations with the update enforcer.
Assumptions:
Users will install update enforcer as a prerequisite. Developer has resources to build the update enforcer service mechanism.
Advantages:
Same reduced performance hit. Re-usability (given a generic enough implementation). Allows for update enforcement with a hard shutdown and allows for control of the offline scenario.
Disadvantages:
A developer has to implement the service.
As I said before, I believe VSTO ClickOnce does and doesn't support the push deployment model. Depending on the degree of closeness to an actual push model and the number of factors involved it is very possible to address many of scenarios that may require a push model. I think it would be very doable to create a generic 2 project solution that contains both the end client service and administrative controller for the update enforcer, i would be interested to know how many people are interested in such a technology.
I think that's about all I want to talk about today, I've been super busy this week with projects that I can't talk about and with Burnout:Paradise in my spare time. As always, I do respond to questions and comments posted.
Thank you for reading,
Kris