Why does VS2013 publish all website files when using a different machine?

Question

I have a home machine and office machine I use to publish websites using Visual Studio 2013. If I make a change from the same machine, and re-publish, just the changes are published, not all files.

However, when using my clone machine at the office, even if I do a get latest, make one small change, and re-publish, all files are published, not just the ones that changed, and not just the ones that have been recompiled. ALL dll files, even third party dlls that have not changed or have been recompiled with a new date, are republished. Same thing happens if my cohort publishes a small change on his machine after I did the last publish. Not a problem if publishing twice from the same machine as then only the changed files are published.

Is there anyway to prevent complete republishing just because a different machine is used to publish than the one used for the last publish? Thanks.

Answer 1

This seems to make "Determining Changes" a lot slower, but for .Net 4.5 [and up(?)], use this info from: https://msdn.microsoft.com/en-us/library/ee942158:

To configure Web Deploy to use checksums instead of dates to determine which files need to be copied to the server, add the following element to the .pubxml file (Publish Settings):

<MSDeployUseChecksum>true</MSDeployUseChecksum>

Like this:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSDeployUseChecksum>true</MSDeployUseChecksum>
    <!— other settings omitted to keep the example short -->
    <PublishDatabaseSettings>
      <!— this section omitted to keep the example short -->
    </PublishDatabaseSettings>
  </PropertyGroup>
</Project>

Answer 2

First of all, I do not understand the behavior of MSBuild+VS2013 and the publishing feature completely as I just started to use the publishing feature myself. I'm looking for a way to speed up publishing via FTP web deploy in VS2013. (I'm not using TFS for a get latest though.)

I would say this is partially explained in a different context at this SO question. The MSBuild process. Timestamps of certain files are being compared and then could indicate MSBuild/VS2013 whether a target (build output) is up-to-date or not. Then files that are not up-to-date are being recompiled. As you all work on different machines, timestamps are likely to be different quite soon.

To find out what is actually going on during builds/publishes, set build output verbosity to detailed or diagnostic, for a moment: VS2013 menu - Tools - Options... - Project and solutions - Build and run - output verbosity - set to -> detailed or diagnostic. Run the build, and see the Output panel/tab in VS2013. Select "show output from: Build" to see results if not already visible. Don't forget to set it to the original setting after checking the build details, as it could slow the build down a bit.

But why even unchanged third party dll's are being republished? Possibly because these dll's ARE actually overwritten during a build. You might have the assembly reference property "Copy local" set to true to get your website running without any manual uploads to be done for this. Or you are using a commandline copy command with the overwrite parameter explicitly set to true during project's post build event (like 'copy /y ...' or 'xcopy /y ...'). Then the timestamp of the file that is to be published is overwritten for sure, see in the "obj\Release\Package\PackageTmp" folder (or for example: "\Debug" instead of "\Release" if Debug build is set for the selected publish profile.)

Furthermore, VS2013 as default does NOT check timestamp differences on the targeted webserver if you are using FTP publishing, at least that is my experience. As for the other publishing options like a web deploy I don't know yet. But the differences you experience seem normal behavior to me, as you run builds on different machines and publishing files from different machines as well. So timestamps are likely to be different... which, again, indicates 'changed' files to be published.

As I'm curious how this question should be solved, I was looking for this in the first place: Maybe a TFS build server is an option for you, configured with a rolling build. But I read on a specific SO (sorry, can't add more links at this moment as I've just registered) that is suggesting to do clean builds to prevent new problems. And that will force full publishing again as files are all being changed by the clean build... so that won't work I think.

As an answer, you might want to use these FAQ answers on MSDN for web deployments. See the questions:

1. "Can I exclude specific files or folders from deployment?" .NET 4.0/4.5 and/or
2. "How to make Web Deploy use file checksums instead of dates to determine which files were changed?" .NET 4.5 only!

The first option is to exclude files. The second option is to use a checksum to compare files instead of timestamps, but that could be somewhat slowing the build(?) process, as the FAQ says. Note the first few lines on that FAQ pages, on how you can edit your publishing profile to apply one or both of these elements!

Also it is an option to put the thirdparty dll's in a different project which you then could only include that project in the deploy for a certain solution configuration (VS2013 menu - Build - Configuration Manager, see the checkboxes in the 'deploy' column there for every project. Though I'm not sure if this is part of the VS2013 'publish' feature as a web deployment, because this deploy column checkboxes are greyed out for my solution projects for some reason I don't understand yet... so I can't test it to verify this option.)

Though it sounds logic, don't forget to create backups/copies/screenshots first before you change any settings or publishing profiles, and then change the same settings/configurable files on the other machines you and your colleagues work at.