I am ready to start testing the ClickOnce deployment goo on my app that I am converting from VS2003 to VS2005 just for this feature. I have been trying to enable some type of web server update since late 2002 when we learned about zero-touch deployment. But because I had some very special needs, my constant revisit to the problem using the various tools that have been available over the past few years have all ended in dissappointment.
I found some great videos to get me started. Thom Robbins' ClickOnce demo is very basic, but a perfect start. Then I followed that up with this video by Sean Puffet which took me a bit further.
Unfortunately, I learned that I will have to dive deeper to solve my biggest two problems.
1) I need to have some special security features for ex-employees of the company who have this app installed remotely.
2) I have a gaggle of plug-in assemblies (and the list will grow) that ClickOnce will not discover through reflection and therefore will not be added to the manifest.
So my next stop was the TechEd 2005 "Real World ClickOnce", first presented at TechEd US by Patrick Darragh from the VB Team. In this session, I could see where I needed to go but there were, unfortunately, no hard examples of exactly how to do it.
Here's my plan for now.
Patrick showed using server side extensions to manage the updates. In effect, he created a web page where a user logs in and then clicks an "Update" button. Based on the user's login, a manifest file is created dynamically by querying the contents of database tables and then the user gets a customized update. As Patrick does not show us the code behind the update button, I have no clue how the manifest file is built - my challenge for today, I suppose.
So I will go this route, but with my own twist. I do not want to ask the users to do this extra step of going to a website for the update Instead, I will build this functionality as a web service. The application already uses web services for it's backend (when they are online) and to download data for offline usage.
Therefore I will let them start up their smart client as they always do and then after they do their login, hit a web service that will handle the update. I foresee only two update roles here - valid and invalid. Invalid will be the ex-employees and that will have a different effect. But for all logins that fall into the valid role, I can then handle the update - they will all get the same bits.
I'm assuming (and hoping) that this process will only bother updating necessary assemblies. Therefore, if one person hasn't updated in a while, it might bring down more files than someone who updated more recently. If I'm lucky, I won't have to manage that myself. On the other hand, this would also mean I have built in a nice little tracking system of who has updated lately.
So, we'll see how it goes. Hopefully, I'm on the right track.