I have not been able to try out Whidbey's ClickOnce deployment yet, but reading through the documentation I could find, I still have a few questions. These questions come from what we had to do to get the Updater Application Block to work for our situation.
In some corporate environments, there are ten-thousand desktops using a server or mainframe for a backend. Development for the desktop and the mainframe occur simultaneously, but may not go into production at the same time. The code for the desktops and mainframe need to go live on the same date. If the desktop code is available before that date, it seems reasonable to have the desktops download the new version before the live date and just not start it until that time. Will the new ClickOnce offer this feature? If not, will there be a way to for developers to extend ClickOnce?
Second, is there a way to split users into groups. Some companies prefer split their users into groups and have them update at different times, usually with a group acting as beta testers with other groups following at certain time periods. I understand that this can be accomplished by specifying a different manifest for each group, but this would also require that the groups be created in advance changes in the groups would require a change at individual workstations to point them to the new group.
Third, it appears that ClickOnce will allow you to just download files that have changed, unlike the UAB. How does it determine that a file has changed? Does it go by the version number in assemblies? What does it do for files that are not assemblies (ex - XML files, config files, etc. ). Is there a way to force a download of application files even if the version numbers have not changed, if version numbers are used?
Fourth, does ClickOnce depend on BITS? Is there a way to specify that a straight HTML downloader be used for check upon application startup but use BITS for downloading in the background during application runtime if an update appears later?
Any answers you can supply would be most appreciated.
| | WinFormsUser | Hi Minton. Some good quesitons. Answer below:
1) Download but don't activate is unfortunately not directly supported. If your super determined there are ways to partially achieve this... but it's a bit messy. This is really part of the background download feature we don't have yet. See #4.
2) There are several ways to accomplish the user segmentation. One is different deployment manifests (you can have the web page render the link to the right one based on who the user is). You can tie this with the System.Deployment APIs. With these apis you can do your own update checks... perhaps calling a web service to ask if an update is available for this user. If so, just call our system.deployment api & we'll do the udpate.
3) ClickOnce uses file hashes to detect changes. You can have xml, config, etc.. files in your app. When they change, ClickOnce will download them.
4) CLickOnce does not use BITS for the simple reason that BITS is not suppoted on my .NET Framework supported platforms. You can use the System.Deployment APIs to control when an app checks for updates, but there is no native background trickle download support in Whidbey. In Longhorn there will be. | | WinFormsUser | Thank you for the quick response. I am trying make sure that we can switch to ClickOnce deployment when it is available instead of continuing with our own version of the Updater Application Block in which we have implemented the extra features I mentioned above, so your response are very helpful. I have some followup questions, however.
1) Is it possible that Using hashes to detect changes might be problematic? If the build number is included as part of the version number, the hash of the assembly will change even if the actual version number does not, so the assembly will always be downloaded.
2) Will there be command line versions of the deployment utilities? Our developers will never be deploying anything themselves.
3) If we are unable to do everything we need with ClickOnce, will there be a way to extend it? | | WinFormsUser |
1) Great question. I'll check & get back. If it does, you could always use the original files... but clearly that's not ideal in terms of an automated process.
2) Yes, you will have two cmd line options. a tool called mage.exe (manifest generator & editory... also has a UI version) in the .NET SDK & you can use the msbuild tasks that VS uses to do it's manifest generation at the cmd line.
3) It depends, I can't promise you can extend ClickOnce to do anything. The main set of extensiblity for ClickOnce is the system.deployment apis & the fact that it's just using HTTP, so you can do a lot of interesting things on what the server sends back to ClickOnce. I've talked with quite a number of customers that wanted to do something not quite in the scope of what clickonce directly supports & we were able to find ways they could accomplish what they need to do using one of those mechanisms. | | WinFormsUser |
|
index > ClickOnce and Setup & Deployment Projects > Deployment options