ASP.NET Core Blazor 项目发布时清理问题的分析与解决方案

在开发基于 ASP.NET Core Blazor 的 Web 应用程序时，开发人员可能会遇到一个常见但容易被忽视的问题：使用增量发布时，每次发布操作都会在目标文件夹中累积生成新的 wasm 文件，而不会自动清理旧版本文件。这个问题不仅会导致发布目录体积不断膨胀，还可能引发潜在的版本冲突问题。

问题现象

当开发人员使用 dotnet publish 命令发布 Blazor Web App 项目时，每次发布都会在 publish\wwwroot\_framework 目录下生成新的 wasm 文件及其压缩版本（.br 和 .gz）。这些文件会以不同的哈希后缀命名，例如 BlazorApp1.Client.5kb6whmwhl.wasm 和 BlazorApp1.Client.xrqucjflwi.wasm。

在典型的开发流程中，随着代码的频繁修改和多次发布，这个目录中的文件数量会持续增加。有开发人员报告称，在几天内发布目录的体积就增长了超过 100MB，这显然不是期望的行为。

问题根源

这个问题的本质在于 .NET 发布机制的设计选择。默认情况下，dotnet publish 命令不会在执行发布操作前自动清理目标文件夹。它只是基于项目当前状态生成必要的部署文件，并将它们放置到指定的输出文件夹中。

对于 Blazor WebAssembly 项目，每次构建都会生成带有唯一哈希值的 wasm 文件，以确保浏览器能够正确缓存和加载最新版本。然而，发布机制没有自动清理旧版本文件的逻辑，导致这些文件在发布目录中不断累积。

解决方案

针对这个问题，开发人员可以采取以下几种解决方案：

1. 手动清理发布目录：在每次发布前手动删除发布目录中的内容。这种方法简单直接，但容易忘记执行。

2. 使用 MSBuild 目标自动化清理：更优雅的解决方案是通过自定义 MSBuild 目标在发布前自动清理目录。以下是一个实现示例：

<Target Name="_RemovePublishDirBeforePublishing" BeforeTargets="BeforePublish">
    <RemoveDir Directories="$(PublishDir)" Condition="'$(PublishDir)' != ''" />
</Target>

开发人员可以将这段代码添加到项目文件中，或者将其保存为独立的 .targets 文件并放置在 MSBuild 的 ImportAfter 目录中。

3. 指定新的输出目录：每次发布时使用不同的输出目录，避免文件累积问题。可以通过 --output 参数指定新的发布目录。

最佳实践建议

对于生产环境部署，建议采用以下最佳实践：

1. 始终在干净的目录中进行发布操作，确保不会遗留旧版本文件。

2. 考虑在 CI/CD 流水线中集成自动清理步骤，保证每次构建都是从干净状态开始。

3. 对于大型项目，定期检查发布目录体积，确保不会因文件累积导致部署包过大。

4. 在团队开发环境中，建议将清理逻辑标准化，可以通过共享的 .targets 文件或项目模板确保所有成员使用相同的发布流程。

通过理解这个问题的本质并实施适当的解决方案，开发人员可以确保 Blazor 应用程序的发布过程更加可靠和高效，避免因文件累积导致的各种潜在问题。