Sayed Y. Hashimi

If you have an automated build process around a ClickOnce deployment, you should know how ClickOnce determines updates to files. Why is this important? Well, lets say that you are using MSBuild to do scheduled builds every day (say 3 times a day). Your build process starts out by getting the lastest code from your source control system and then builds all the projects and assemblies of your application. It then creates the application and deployment manifest (the ClickOnce manifest files) and then pushes updates to the deployment server.

The potential problem with this approach is that if your build process rebuilds all of the assemblies used by your application, even if they were not modified, then ClickOnce will think the file has changed and will have to download the entire application again--just as if it were the initial install. This is an obvious problem and it has to do with how ClickOnce calculates a change to a file.

ClickOnce is driven by two manifest files: the application manifest and the deployment manifest. The application manifest has details about a particular version of an application. For example, the dependent assemblies of a particular version of an application. The deployment manifest has details about the application as a whole and not specific details about a particular version. The deployment manifest, for example, will have the update policy of the application.

Going back to our problem. I said that the application manifest has details about the files that comprise a specific version of an application. For example, if an application depends on an assembly called "MyCoolAssembly", then the application manifest will have an <dependency> tag for that assembly. Each file in the manifest has an associated hash that ClickOnce uses to determine if the file has changed. Actually, the hash is used for two things: 1) to determine changes to a file and, 2) to detect file tampering.

If your build process recreates assemblies, even if they were not modified, then ClickOnce will not know that the two files are identical. ClickOnce determines changes to files by comparing the file hash on client with what's on the server (in the application manifest). If the two files have the same hash, then ClickOnce doesn't download the file again, it simply copies the file from one directory to another.

There are several things to think about when you start to build an automated ClickOnce deployment.

1. Identify any 3rd party assemblies and be sure not to rebuild these files; put these files in a well-known folder and have the build process copy them.
2. If you have assemblies that you share across projects/solutions, establish a mechanism in your build process that will detect changes to files in these projects and will rebuild only when necessary.
3. The core of your application can be rebuild depending on how large the project is.

Generally, items 1) and 2) will make up a significant part of an application and needs to be addressed properly from the context of a ClickOnce deployment.