PAYATHON 2026

如何让 Visual Studio 2026 仅发布发生更改的文件？

排障赵师傅

这份配置使用 Web Deploy，正常情况下会自动比较源端和目标端，只传输有差异的文件，无需额外开启“增量发布”。仅凭这份 .pubxml，还无法确定升级到 Visual Studio 2026 后发布变慢的原因，也不能认定该版本每次都会全量上传。Web Deploy 官方说明

MSDeployUseChecksum 用来改变文件比较方式，SkipExtraFilesOnServer 控制是否保留服务器上的额外文件。既然启用校验和后仍未改善，就需要检查实际上传记录，并确认属性是否生效。

两个属性分别控制什么

将 SkipExtraFilesOnServer 设为 true，会保留目标端存在、源端没有的文件。它不会阻止同名文件更新，也不参与判断文件是否发生变化。可以保留现有设置，但它无法解决重复上传的问题。发布设置说明

Web Deploy 支持按时间戳或 CRC 校验和判断文件差异。启用以下属性后，会使用校验和比较文件：

<MSDeployUseChecksum>true</MSDeployUseChecksum>

如果文件内容相同，只有时间戳变化，这项设置有助于减少重复传输。不过，计算校验和也需要读取文件，因此发布总时间未必会缩短。微软对文件比较方式的说明

先确认是否真的重新上传了所有文件

发布包含构建、准备发布目录、远端比较和传输等阶段。输出窗口列出所有文件，或本地发布目录重新生成，都不能直接证明这些文件已全部上传。

保留当前构建产物，不修改代码，连续发布两次，查看第二次发布的 Web Deploy 输出：

  • 如果时间主要花在构建或复制到本地暂存目录上，检查构建过程和自定义发布脚本。
  • 如果大量文件出现远端 Updating file 记录，检查文件差异和校验和设置。
  • 如果远端更新很少，发布却仍然耗时，检查比较阶段、网络、服务器磁盘和备份操作。

配置中的 EnableMSDeployBackup 为 true。如果日志显示耗时主要来自服务器备份，就需要单独处理备份问题，不能据此判断增量同步失效。

在实际使用的发布配置中确认校验和生效

修改当前选中的发布配置所对应的文件：

Properties/PublishProfiles/你的配置名.pubxml

在已有的 <PropertyGroup> 中保留或添加：

<SkipExtraFilesOnServer>true</SkipExtraFilesOnServer>
<MSDeployUseChecksum>true</MSDeployUseChecksum>

题目展示的配置中没有 MSDeployUseChecksum，需要确认它已保存到实际使用的发布配置中。

.NET SDK 的发布目标会把 MSDeployUseChecksum 传给部署任务的 UseChecksum 参数。排查时，还需要确认任务最终收到的值，单看 .pubxml 中的设置不够。.NET SDK 发布目标源码

可以在 Visual Studio 2026 的 Developer Command Prompt 中，对入口 Web 项目执行一次带日志的发布：

msbuild MyWebApp.csproj /t:Build /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=MyProfile /p:MSDeployUseChecksum=true /v:diag /bl:publish.binlog

将项目名和配置名替换为实际值。这条命令会执行真实部署，需要具备目标服务器的发布凭据。/p:PublishProfile 的用法见发布配置文档。

检查日志时，确认以下几点：

  • 加载的发布配置是否正确。
  • 部署任务的 UseChecksum 是否为 true；使用 msdeploy.exe 时，是否传入了 -useChecksum。
  • 哪个阶段耗时最多，哪些目标文件被更新。

发布日志可能包含连接信息或凭据，分享前需要检查并脱敏。

校验和已启用，仍然重复上传怎么办

选一个确定没有更新过的第三方 DLL，比较本次实际部署的文件和服务器上的对应文件。可以先下载服务器文件，再分别计算哈希：

Get-FileHash "C:\PublishOutput\SomeDependency.dll" -Algorithm SHA256
Get-FileHash "C:\ServerCopy\SomeDependency.dll" -Algorithm SHA256

这里的 SHA256 用于人工验证文件内容是否一致，与 Web Deploy 使用的 CRC 比较机制不同。

如果哈希不同，说明部署文件确实发生了变化，需要继续检查构建后的处理步骤，例如程序集重写、混淆或其他自定义操作。即使项目源码没有修改，最终发布文件也未必逐字节相同。

如果哈希相同，已传入 UseChecksum=true，但日志仍显示该文件被重复更新，就需要检查部署执行方式，以及客户端和服务器端的 Web Deploy 环境。此时继续添加无关属性无助于排查。

可以临时加入以下属性，做一次对照：

<UseMsdeployExe>true</UseMsdeployExe>

该属性会让支持此分支的发布流程调用 msdeploy.exe。SDK 源码中同时存在两种执行路径，都会接收校验和设置。这项实验用于定位执行路径的差异，尚不能当作已确认的 Visual Studio 2026 修复方案。发布任务实现

如何判断是否属于版本回归

使用同一份源代码、同一个目标站点和相同的发布参数，对比 VS 2022 与 VS 2026 的日志，同时记录实际使用的 .NET SDK 和 Web Deploy 版本。TargetFramework 为 net6.0 只说明应用的目标框架，不能据此判断两次发布使用了相同的 SDK。

如果 VS 2022 能跳过内容相同的文件，VS 2026 却在相同条件下重复更新，才有依据进一步排查工具链回归。现有信息还不足以确定具体的故障版本或修复版本。

这份配置可以保留 SkipExtraFilesOnServer=true，先确认 MSDeployUseChecksum=true 实际生效，再根据日志判断耗时来自重复传输还是其他发布阶段。不要通过排除所有第三方 DLL 来提速，否则以后更新依赖时容易漏发。

备注：内容仅供参考。