... ou comment j'ai appris à cesser de m'inquiéter et à écrire simplement du code contre des API complètement non documentées de Microsoft . Existe-t-il une documentation réelle de la System.Web.Optimizationversion officielle ? Parce que je ne peux certainement pas en trouver, il n'y a pas de documents XML et tous les articles de blog font référence à l'API RC qui est sensiblement différente. Anyhoo ..
J'écris du code pour résoudre automatiquement les dépendances javascript et je crée des bundles à la volée à partir de ces dépendances. Tout fonctionne très bien, sauf si vous modifiez des scripts ou apportez des modifications qui affectent un bundle sans redémarrer l'application, les modifications ne seront pas reflétées. J'ai donc ajouté une option pour désactiver la mise en cache des dépendances à utiliser dans le développement.
Cependant, apparemment BundleTablesmet en cache l'URL même si la collection de bundles a changé . Par exemple, dans mon propre code, lorsque je souhaite recréer un bundle, je fais quelque chose comme ceci:
// remove an existing bundle
BundleTable.Bundles.Remove(BundleTable.Bundles.GetBundleFor(bundleAlias));
// recreate it.
var bundle = new ScriptBundle(bundleAlias);
// dependencies is a collection of objects representing scripts,
// this creates a new bundle from that list.
foreach (var item in dependencies)
{
bundle.Include(item.Path);
}
// add the new bundle to the collection
BundleTable.Bundles.Add(bundle);
// bundleAlias is the same alias used previously to create the bundle,
// like "~/mybundle1"
var bundleUrl = BundleTable.Bundles.ResolveBundleUrl(bundleAlias);
// returns something like "/mybundle1?v=hzBkDmqVAC8R_Nme4OYZ5qoq5fLBIhAGguKa28lYLfQ1"
Chaque fois que je supprime et recrée un bundle avec le même alias , absolument rien ne se passe: le bundleUrlretour de ResolveBundleUrlest le même qu'avant de supprimer et recréer le bundle. Par «le même», je veux dire que le hachage du contenu est inchangé pour refléter le nouveau contenu du bundle.
modifier ... en fait, c'est bien pire que ça. Le bundle lui - même est mis en cache en dehors de la Bundlescollection. Si je génère simplement mon propre hachage aléatoire pour empêcher le navigateur de mettre en cache le script, ASP.NET renvoie l'ancien script . Donc, apparemment, supprimer un bundle de BundleTable.Bundlesne fait rien.
Je peux simplement changer l'alias pour contourner ce problème, et c'est OK pour le développement, mais je n'aime pas cette idée car cela signifie soit que je dois déprécier les alias après chaque chargement de page, soit avoir un BundleCollection qui grossit sur chaque chargement de page. Si vous laissiez cela activé dans un environnement de production, ce serait un désastre.
Il semble donc que lorsqu'un script est servi, il est mis en cache indépendamment de l' BundleTables.Bundlesobjet réel . Donc, si vous réutilisez une URL, même si vous avez supprimé le bundle auquel elle faisait référence avant de la réutiliser, elle répond avec ce qui se trouve dans son cache, et la modification de l' Bundlesobjet ne vide pas le cache - donc seuls les nouveaux éléments (ou plutôt, de nouveaux éléments avec un nom différent) seraient jamais utilisés.
Le comportement semble étrange ... supprimer quelque chose de la collection devrait le supprimer du cache. Mais ce n'est pas le cas. Il doit y avoir un moyen de vider ce cache et de lui faire utiliser le contenu actuel du BundleCollectionplutôt que ce qu'il a mis en cache lors du premier accès à ce bundle.
Une idée de comment je ferais ça?
Il y a cette ResetAllméthode qui a un but inconnu mais qui casse les choses de toute façon, donc ce n'est pas ça.
