... ou comment j'ai appris à cesser de s'inquiéter et il suffit d'écrire le code contre complètement sans-papiers Api de Microsoft. Est-il réel de la documentation officielle de l' System.Web.Optimization version? car je ne trouve pas, il n'y a pas de docs XML, et tous les articles de blog reportez-vous à la RC de l'API qui est sensiblement différent. Anyhoo..
Je suis en train d'écrire un peu de code pour résoudre automatiquement javascript dépendances et suis à la création d'ensembles à la volée à partir de ces dépendances. Tout fonctionne très bien, sauf si vous modifiez les scripts ou sinon faire des changements qui affectent un bundle sans redémarrage de l'application, les changements ne seront pas pris en compte. J'ai donc ajouté une option pour désactiver la mise en cache des dépendances pour une utilisation dans le développement.
Cependant, apparemment BundleTables caches de l'URL , même si le bundle de la collection a changé. Par exemple, dans mon code, quand je veux re-créer un bundle-je faire 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 l'ai supprimer et recréer un bundle avec le même alias, absolument rien ne se passe: l' bundleUrl retourné à partir de ResolveBundleUrl est le même qu'avant, que j'ai supprimé et recréé le bundle. Par "le même", je veux dire que le hachage du contenu est inchangé pour refléter le nouveau contenu du bundle.
edit... en fait, c'est bien pire que cela. Le faisceau lui-même est mis en cache en quelque sorte à l'extérieur de l' Bundles de la collecte. Si je générer mon propre aléatoire de hachage pour empêcher le navigateur de mise en cache le script, ASP.NET retourne l'ancien script. Donc, apparemment, la suppression d'un bundle BundleTable.Bundles ne font rien.
Je peux simplement modifier 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 que j'ai à rendre caduque alias après chaque chargement de la page, ou d'avoir une BundleCollection qui grandit à chaque chargement de page. Si vous avez quitté ce dans un environnement de production, ce serait une catastrophe.
Il semble donc que lorsqu'un script est servi, il obtient en cache indépendante de la BundleTables.Bundles objet. Donc, si vous ré-utiliser une URL, même si vous avez supprimé le paquet qu'elle se réfère à avant de le réutiliser, il répond avec tout ce qui est dans son cache, et de la modification de l' Bundles objet n'est pas de vider le cache -- donc, seuls les nouveaux éléments (ou plutôt, de nouveaux éléments avec un nom différent) pourrait jamais être utilisé.
Le comportement semble bizarre... de retirer quelque chose de la collection devrait le supprimer de la mémoire cache. Mais il ne le fait pas. Il doit y avoir un moyen de vider le cache et l'avoir utiliser le contenu actuel de l' BundleCollection au lieu de ce qu'il cache ce bundle a d'abord été consulté.
Une idée de comment je pourrais faire cela?
Il y a cette ResetAll méthode qui a un inconnu but, mais c'est juste casse choses, de toute façon, de sorte que n'est-il pas.
