Updated validation logic for Static Web Assets

[javiercn]

Updated validation logic for Static Web Assets

There was a bug in the way Static Web Assets validated the existence of conflicting assets in ASP.NET Core 3.1 and Blazor Webassembly 3.2 that prevented conflicts between the host assets and the assets coming from razor class libraries and Blazor Webassembly applications from being detected properly.

This mostly affects Blazor Webassembly applications since by default static web assets in Razor Class Libraries are served under the _content/$(PackageId) prefix.

Version introduced

5.0

Old behavior

Before these changes, static web assets coming from razor class libraries could be silently overridden during development with assets from the host project placed on the same host path. For example, if a razor class library defined a static web asset to be served under /folder/file.txt and the host placed a file under wwwroot/folder/file.txt the file on the server would silently override the file on the Razor Class Library or Blazor Webassembly application.

New behavior

ASP.NET Core will now correctly detect when this issue happens and inform of the conflict so that users can be aware and take the appropriate action.

Reason for change

This was a bug in the implementation, we never intended for static web assets to be "overridable" by files on the wwwroot host of the project since that leads to errors that are hard to diagnose and can result in undefined behavior changes when applications are published.

Recommended action

There should be no reason for a file on a Razor Class Library to conflict with a file on the host by default since they are prefixed with _content/${PackageId} unless we are discussing Blazor Webassembly applications, which get placed by default at the root of the host url space, which makes conflicts easier. (For example, Blazor Webassembly Applications contain a favicon.ico that the host might also include in their wwwroot folder).

If the source of the conflict is a file in a Razor Class Library it normally means there is some code that copies the assets from the library into the wwwroot folder of the project. We don't recommend developers doing that since it defeats one of the main goals of static web assets which is that files don't have to be copied around, which is fundamental to get updates on the browser when the contents are updated without having to trigger a new compilation.

If despite that you want to preserve this behavior and maintain the file on the host, you can do so by removing the file from the list of static web assets with a custom MSBuild target.

If you want to use the file on the razor class library or the blazor webassembly file instead of the file from the host project, just remove the file from the host project.

Category

ASP.NET

Affected APIs

"Not detectable via API analysis"

---

Issue metadata

• Issue type: breaking-change