Updated validation logic for Static Web Assets #443
Labels
5.0.0
Announcements related to ASP.NET Core 5.0
Announcement
Breaking change
Documented
The breaking change has been published to the .NET Core docs
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 underwwwroot/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
The text was updated successfully, but these errors were encountered: