Freigeben über

Blazor: Aktualisierte Validierungslogik für statische Webressourcen

Es gab ein Problem bei der Konfliktüberprüfung für statische Webressourcen in ASP.NET Core 3.1 und Blazor WebAssembly 3.2. Das Problem:

  • Es verhinderte die korrekte Konflikterkennung zwischen den Host-Assets und den Assets aus Razor-Klassenbibliotheken (RCLs) und Blazor WebAssembly-Apps.
  • Wirkt sich hauptsächlich auf Blazor WebAssembly-Apps aus, da statische Webressourcen in RCLs standardmäßig unter dem _content/$(PackageId) Präfix bereitgestellt werden.

Eingeführte Version

5.0

Altes Verhalten

Während der Entwicklung können die statischen Webressourcen einer RCL unbemerkt mit Ressourcen des Hostprojekts auf demselben Hostpfad überschrieben werden. Erwägen Sie eine RCL, die eine statische Webressource definiert hat, die bei /folder/file.txtbereitgestellt werden soll. Wenn der Host eine Datei in wwwroot/folder/file.txt platzierte, überschrieb die Datei auf dem Server ohne Warnung die Datei in der RCL oder in der Blazor WebAssembly-App.

Neues Verhalten

ASP.NET Core erkennt ordnungsgemäß, wenn dieses Problem auftritt. Er informiert Sie, den Benutzer, über den Konflikt, damit Sie die entsprechende Aktion ausführen können.

Grund für Änderung

Statische Webressourcen waren nicht dafür vorgesehen, von Dateien auf dem wwwroot-Host des Projekts überschrieben zu werden. Das Zulassen der Außerkraftsetzung dieser Dateien kann zu Fehlern führen, die schwierig zu diagnostizieren sind. Das Ergebnis könnte nicht definierte Verhaltensänderungen in veröffentlichten Apps sein.

Standardmäßig gibt es keinen Grund, dass eine RCL-Datei mit einer Datei auf dem Host in Konflikt stehen soll. RCL-Dateien sind mit dem Präfix _content/${PackageId} versehen. Blazor WebAssembly-Dateien werden am Stamm des Host-URL-Bereichs platziert, wodurch Konflikte leichter entstehen können. Beispielsweise enthalten Blazor WebAssembly-Apps eine favicon.ico Datei, die der Host möglicherweise auch in seinen wwwroot-Ordner aufnehmen kann.

Wenn es sich bei der Quelle des Konflikts um eine RCL-Datei handelt, bedeutet dies häufig, dass Code Objekte aus der Bibliothek in den Wwwroot-Ordner des Projekts kopiert. Das Schreiben von Code zum Kopieren von Dateien untergräbt ein Hauptziel statischer Webressourcen. Dieses Ziel ist es, Updates für den Browser zu erhalten, wenn die Inhalte aktualisiert werden, ohne eine neue Kompilierung auslösen zu müssen.

Sie können dieses Verhalten beibehalten und die Datei auf dem Host verwalten. Entfernen Sie dazu die Datei aus der Liste der statischen Webobjekte mit einem benutzerdefinierten MSBuild-Ziel.

Um die Datei der RCL oder die Datei der Blazor WebAssembly-App anstelle der Datei des Hostprojekts zu verwenden, entfernen Sie die Datei aus dem Hostprojekt.

Betroffene APIs

Nichts