By default WebDeploy/MSDeploy only deploys “changed” files. There are two ways that WebDeploy checks for changed files: by timestamp and checksum. In this blog post we will compare these options.
Timestamp
By default WebDeploy uses the timestamp method to identify changed files. If you try to deploy the same package twice you will see it will deploy all the files and then no files on the second run.
c:\Visual Studio 2015\WebApplication1\obj\Debug\Package>WebApplication1.deploy.cmd /y /M:localhost ... Total changes: 116 (113 added, 0 deleted, 3 updated, 0 parameters changed, 23296247 bytes copied) c:\Visual Studio 2015\WebApplication1\obj\Debug\Package>WebApplication1.deploy.cmd /y /M:localhost ... Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
The typical problem developers see is some files’ timestamps are updated when creating a new package. So even potentially unchanged files will be flagged as new because of the new timestamp in the new build/package.
If we rebuild the project without making any code changes and deploy the new package you will see it redeploys the dll, pdb and config files:
... Info: Using ID 'ae6e99b6-a810-41f4-859f-58fce794f8c5' for connections to the rem ote server. Info: Updating file (Default Web Site/WebApplication1_deploy\bin\WebApplication1.dll). Info: Updating file (Default Web Site/WebApplication1_deploy\bin\WebApplication1.pdb). Info: Updating file (Default Web Site/WebApplication1_deploy\Views\Web.config). Info: Updating file (Default Web Site/WebApplication1_deploy\Web.config) ... Total changes: 4 (0 added, 0 deleted, 4 updated, 0 parameters changed, 185240 bytes copied)
Checksum
The second option compares each file using a checksum value instead of datetime. To use this method you can use
the -useChecksum
WebDeploy flag if deploying via the deploy.cmd or MSDeploy.exe:
c:\Visual Studio 2015\WebApplication1\obj\Debug\Package>WebApplication1.deploy.cmd /y /M:localhost -useChecksum
If you are deploying during the MSBuild process you can add the /p:MSDeployUseChecksum=true
argument which will set the MSDeploy flag.
With this change we now only have two updated files during the deployment:
... Info: Updating file (Default Web Site/WebApplication1_deploy\bin\WebApplication1.dll). Info: Updating file (Default Web Site/WebApplication1_deploy\bin\WebApplication1.pdb). Total changes: 2 (0 added, 0 deleted, 2 updated, 0 parameters changed, 178176 bytes copied)
The dll and pdb have slight binary differences between builds so they are still deployed but you can see the config files are not.
TFS/CI Process
The code examples used in this blog post are based on local builds/deployments and don’t highlight how useful the checkum method can be. We find this much more useful in our CI process where we use TFS to build and create our deployment packages. In most cases the TFS build cleans the directory for each new build which updates the file timestamps and thus will redeploy all the files for the site between builds.
We have seen deploy times reduced by 50-90% by using the checksum flag in some cases. If you notice your deployments are deploying unchanged files give it a try and see if it helps. If it helps you please leave a comment with your deployment times for others to learn from.
Thanks a ton !!
Talking of the checksum concept do you have any idea how msdeploy would respond in case the the artifact is tampered with during deployment, does msdeploy perform any kind of md5/sha256 checksum to validate the file integrity? If it does, do you have any idea how it would respond to such an incident? Thanks!
It uses a CRC checksum to determine if the file in the deployment package is different from the file on the target server so it knows whether to publish the file to the target. This isn’t a security feature. If a file were tampered with it would always deploy.