Partager via


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

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

  • Empêchait une détection appropriée des conflits entre les fonctionnalités de l'hôte et celles 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 RCL sont servies sous le préfixe _content/$(PackageId).

Version introduite

5,0

Ancien comportement

Pendant le développement, les ressources web statiques d’un RCL peuvent être remplacées en mode silencieux par les ressources de projet hôte sur le même chemin d’accès hôte. Considérez une bibliothèque 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 a dépassé silencieusement le fichier sur l’application RCL ou Blazor WebAssembly.

Nouveau comportement

ASP.NET Core détecte correctement le moment où ce problème se produit. Il vous informe, l’utilisateur, du conflit afin que vous puissiez effectuer l’action appropriée.

Raison de la modification

Les ressources web statiques n’étaient pas destinées à être substituables par des fichiers sur l’hôte wwwroot du projet. La possibilité de remplacer ces fichiers peut entraîner des erreurs difficiles à diagnostiquer. Le résultat peut être des modifications de comportement non définies dans les applications publiées.

Par défaut, il n’existe aucune raison pour qu’un fichier RCL soit en conflit avec un fichier sur l’hôte. Les fichiers RCL sont préfixés par _content/${PackageId}. Les fichiers Blazor WebAssembly sont placés à la racine de l’espace d’URL de l’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 des ressources de la bibliothèque dans le dossier wwwroot du projet. L’écriture de code pour copier des fichiers permet de vaincre 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 conserver 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 du projet hôte, supprimez le fichier du projet hôte.

API affectées

Aucun