Partager via

Blazor : La logique de validation pour les ressources web statiques a été mise à jour

  • Article

Il y avait un problème dans la validation des conflits pour les ressources web statiques dans ASP.NET Core 3.1 et Blazor WebAssembly 3.2. Le problème :

  • Cela empêchait de détecter correctement les conflits entre les ressources hôtes et les ressources provenant des bibliothèques de classes Razor (RCL) et des applications Blazor WebAssembly.
  • Affecte principalement les applications Blazor WebAssembly, car par défaut, les ressources web statiques dans les listes RCL sont traitées sous le préfixe _content/$(PackageId).

Version introduite

5,0

Ancien comportement

Pendant le développement, les ressources web statiques d’un RCL pouvaient être silencieusement remplacées par les ressources de projet hôtes sur le même chemin d’hôte. Considérez une RCL qui a défini une ressource web statique à servir dans /folder/file.txt. Si l’hôte a placé un fichier sur wwwroot/folder/file.txt, le fichier sur le serveur remplace silencieusement le fichier sur l’application RCL ou Blazor WebAssembly.

Nouveau comportement

ASP.NET Core détecte correctement quand ce problème se produit. Il vous informe, vous, l’utilisateur, du conflit afin que vous puissiez prendre les mesures appropriées.

Raison du changement

Les ressources web statiques n’étaient pas destinées à être substituables par des fichiers sur l’hôte wwwroot du projet. L’autorisation du remplacement de ces fichiers peut entraîner des erreurs difficiles à diagnostiquer. Il peut en résulter des changements de comportement non définis dans les applications publiées.

Par défaut, il n’existe aucune raison pour qu’un fichier RCL entre en conflit avec un fichier sur l’hôte. Les fichiers RCL sont précédés de _content/${PackageId}. Les fichiers Blazor WebAssembly sont placés à la racine de l’espace d’URL hôte, ce qui facilite les conflits. Par exemple, les applications Blazor WebAssembly contiennent un fichier favicon.ico que l’hôte peut également inclure dans son dossier wwwroot.

Si la source du conflit est un fichier RCL, cela signifie souvent que le code copie les ressources de la bibliothèque dans le dossier wwwroot du projet. L’écriture de code pour copier des fichiers va à l’encontre de l’objectif principal des ressources web statiques. Cet objectif est fondamental pour obtenir des mises à jour sur le navigateur lorsque le contenu est mis à jour sans avoir à déclencher une nouvelle compilation.

Vous pouvez choisir de maintenir ce comportement et de conserver le fichier sur l’hôte. Pour ce faire, supprimez le fichier de la liste des ressources web statiques avec une cible MSBuild personnalisée.

Pour utiliser le fichier RCL ou le fichier de l’application Blazor WebAssembly au lieu du fichier projet de l’hôte, supprimez le fichier du projet hôte.

API affectées

None