Clear prior deployment troubleshooting guidance

[guardrex]

I've seen this a few times over the years where prior-deployed files can corrupt a fresh deployment. Devs in these cases often resolve the problem by adding a deployment step to wipe the prior deployment completely (e.g., Failed to find a valid digest in the 'integrity' attribute for resource Blazor Wasm (dotnet/aspnetcore #38668)). Also, cross-link the new remark from the integrity PS script section.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: be59faf1-5a20-b7e9-19ff-06589023bb15
• Version Independent ID: 250e7458-3c1d-0117-261d-c03ac136f16a
• Content: Host and deploy ASP.NET Core Blazor WebAssembly
• Content Source: aspnetcore/blazor/host-and-deploy/webassembly.md
• Product: aspnet-core
• Technology: aspnetcore-hostdeploy
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

@TanayParikh ... This is following @alex-oswald's most recent remark at ...

dotnet/aspnetcore#38668 (comment)

... but is something that still happens occasionally for many devs.

Let's discuss potential language here first before I put up a PR. I'd like to focus on a few concepts in a new section of the Host and deploy overview topic. We could add some folks if you think we need more 👀 on it. Chris, Justin, Sourabh, Pranav, Javier ... many have a lot of experience over the years helping devs with this sort of scenario where a corrupted deployment is breaking an app and clearing the prior deployment at least works around the problem. The thing right now tho is that many are out (or going out) on holiday. I'm not sure who's around to look at this! ✈️🏖️😄

• First, this happens less frequently than ever before these days. Four+ years ago in the early days of ASP.NET Core 👴, this was a much more common situation going by what readers were reporting in doc issues. These days, it's much less of a problem AFAICT. Added text should call this out.
• Generally, devs need to do this once for either (or both) the published app or the deployment (on the host). Then, they can usually go back to publishing without replacing the entire app (locally or on the host).
• This shouldn't be a problem under ordinary circumstances: Where the text may say 'you might always need to do this (e.g., in a build pipeline)', we probably should angle this to say that it's a temporary workaround until additional investigation determines why the app is corrupted on the server every time they deploy it.

So ........ something like the following .....................

## Prior deployment corruption

Apps are usually published and deployed without deleting all of the prior files from the previous deployment. When existing files aren't replaced, the typical deployment occurs significantly faster.

In rare cases, lingering files from a prior deployment can corrupt a new deployment. Deleting the existing deployment (or locally-published app prior to deployment) may resolve the issue with a corrupted deployment. Often, deleting the existing deployment once is sufficient to resolve the problem, including when a DevOps pipeline build is in use.

If you determine that clearing a prior deployment is always required when a DevOps build pipeline is in use, you can temporarily add a step to the build pipeline to delete the prior deployment completely for each new deployment until you troubleshoot the exact cause of the corruption.