ClickOnce Via Blob Storage

[RhysC]

http://blogs.msdn.com/b/avkashchauhan/archive/2011/05/09/how-to-deploy-clickonce-application-using-windows-azure-storage-in-very-simple-steps.aspx

This is a trivial example but shows it can easily be done. Things to consider

• versioning
• should the url be publicly available?

[LeeCampbell]

The app can be available publicly. Ideally via a simple url like callwall.com/downloads/clickonce/callwall.deploy (or whatever the ext is for clickonce) Versioning is performed by the clickonce deployment manifest. It acts as a logical version and redirects to the appropriate physical version (package manifest). This allows auto deploy and rollback. Note logical (deployment) version always increments, physical versions may decrement in the case of a rollback, thus these version numbers have nothing to do with each other.

[RhysC]

I assume we will also need to do multiple builds for multiple environments? Should we do "Test" and "Production" for now? I believe the click-once signing process forces you to do a rebuild to rename the app and change the deployment location. From memory we did have to do this at Chevron (ie N builds for N environments), whether that was from lack of understanding or not i cant quite remember.

Step One : I will try to get a very basic prod only click-once working for the web site.

• I think we could have a nice end point in the web proj ie ~/Download/Windows/ that just redirects to a blob storage location where the manifest is (i.e. a static but ugly URL).
• The windows build process would have to be aware of that location and update the manifest in that location. Given it should be sharing the same management certificates I don't see this being a big problem.
• That same build process would have to push each version of the binaries to another public readable location.

I don't see any reason not to keep all of the binaries as Blob storage is so cheap. We can purge manually if and when required.

Step Two: Get it working for Test and Prod We may have a 2 phased build process? perhaps build everything other than the exe (run test etc) and then have a publish step to build the exe with the other projects only as referenced dlls? Maybe this is overboard... not sure

[LeeCampbell]

If you are using a Build process that is not just the simple VS Clickonce packaging, then you would build the dll/exe (strong named etc...) as a first process, then you can generate a package manifest (from MAGE) as a separate step. This will list all of the files in the package, the versions of any assemblies and a hash for the package. This is where you have the opportunity to add old assemblies (i.e. ones that have not changed) and then clickonce will only download the changes. Most people fuck this step up by rebuilding all projects all the time, thus meaning that users have to download all the files even if only one leaf assembly has changed.

Finally, you generate a deployment manifest (MAGE) with a new version number (ie the version of the deployment) which will need to know where it is downloaded from and where to point to for the package manifest.