... o cómo aprendí a dejar de preocuparme y simplemente escribir código contra API completamente indocumentadas de Microsoft . ¿Existe alguna documentación real del System.Web.Optimizationlanzamiento oficial ? Porque seguro que no puedo encontrar ninguno, no hay documentos XML, y todas las publicaciones del blog se refieren a la API RC, que es sustancialmente diferente. Anyhoo ..
Estoy escribiendo un código para resolver automáticamente las dependencias de JavaScript y estoy creando paquetes sobre la marcha a partir de esas dependencias. Todo funciona muy bien, excepto si edita scripts o realiza cambios que afectarían a un paquete sin reiniciar la aplicación, los cambios no se reflejarán. Así que agregué una opción para deshabilitar el almacenamiento en caché de las dependencias para su uso en desarrollo.
Sin embargo, aparentemente BundleTablesalmacena en caché la URL incluso si la colección de paquetes ha cambiado . Por ejemplo, en mi propio código cuando quiero volver a crear un paquete, hago algo como esto:
// 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"
Siempre que elimino y vuelvo a crear un paquete con el mismo alias , no pasa absolutamente nada: el bundleUrldevuelto ResolveBundleUrles el mismo que antes de eliminar y volver a crear el paquete. Por "lo mismo" me refiero a que el hash de contenido no se modifica para reflejar el nuevo contenido del paquete.
editar ... en realidad, es mucho peor que eso. El paquete en sí se almacena en caché de alguna manera fuera de la Bundlescolección. Si solo genero mi propio hash aleatorio para evitar que el navegador almacene en caché el script, ASP.NET devuelve el antiguo script . Entonces, aparentemente, quitar un paquete BundleTable.Bundlesno hace nada.
Simplemente puedo cambiar el alias para solucionar este problema, y eso está bien para el desarrollo, pero no me gusta esa idea, ya que significa que tengo que desaprobar los alias después de cada carga de página o tener un BundleCollection que crece en tamaño en cada carga de página. Si deja esto en un entorno de producción, sería un desastre.
Entonces, parece que cuando se sirve un script, se almacena en caché independientemente del BundleTables.Bundlesobjeto real . Entonces, si reutiliza una URL, incluso si ha eliminado el paquete al que se refería antes de reutilizarlo, responde con lo que sea que esté en su caché, y la alteración del Bundlesobjeto no vacía el caché, por lo que solo los elementos nuevos (o más bien, se usarían elementos nuevos con un nombre diferente).
El comportamiento parece extraño ... eliminar algo de la colección debería eliminarlo del caché. Pero no es así. Debe haber una forma de vaciar esta caché y hacer que use el contenido actual del en BundleCollectionlugar de lo que almacenó en caché cuando se accedió por primera vez a ese paquete.
¿Alguna idea de cómo haría esto?
Existe este ResetAllmétodo que tiene un propósito desconocido pero simplemente rompe cosas de todos modos, así que no es así.
