... ou como aprendi a parar de me preocupar e apenas escrever código em APIs totalmente não documentadas da Microsoft . Existe alguma documentação real do System.Web.Optimization
lançamento oficial ? Porque eu com certeza não consigo encontrar nenhum, não há documentos XML e todas as postagens do blog se referem à RC API, que é substancialmente diferente. Anyhoo ..
Estou escrevendo um código para resolver automaticamente as dependências de javascript e estou criando pacotes dinâmicos a partir dessas dependências. Tudo funciona muito bem, exceto se você editar scripts ou fizer alterações que afetariam um pacote sem reiniciar o aplicativo, as alterações não serão refletidas. Portanto, adicionei uma opção para desativar o armazenamento em cache das dependências para uso no desenvolvimento.
No entanto, aparentemente BundleTables
armazena em cache a URL, mesmo que a coleção do pacote tenha mudado . Por exemplo, em meu próprio código, quando quero recriar um pacote, faço algo assim:
// 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"
Sempre que removo e recrio um pacote com o mesmo alias , absolutamente nada acontece: o bundleUrl
retornado de ResolveBundleUrl
é o mesmo de antes de remover e recriar o pacote. Por "o mesmo", quero dizer que o hash do conteúdo não é alterado para refletir o novo conteúdo do pacote.
editar ... na verdade, é muito pior do que isso. O pacote em si é armazenado em cache de alguma forma fora da Bundles
coleção. Se eu apenas gerar meu próprio hash aleatório para evitar que o navegador armazene o script em cache, o ASP.NET retorna o script antigo . Portanto, aparentemente, remover um pacote de BundleTable.Bundles
não faz nada.
Posso simplesmente mudar o alias para contornar este problema, e isso é bom para o desenvolvimento, mas não gosto dessa ideia, pois significa que tenho que descontinuar os aliases após cada carregamento de página ou tenho um BundleCollection que aumenta de tamanho em cada carregamento de página. Se você deixar isso ativado em um ambiente de produção, será um desastre.
Portanto, parece que quando um script é servido, ele é armazenado em cache independentemente do BundleTables.Bundles
objeto real . Portanto, se você reutilizar um URL, mesmo que tenha removido o pacote ao qual ele se refere antes de reutilizá-lo, ele responde com o que quer que esteja em seu cache e alterar o Bundles
objeto não limpa o cache - portanto, apenas novos itens (ou em vez disso, novos itens com um nome diferente) seriam usados.
O comportamento parece estranho ... remover algo da coleção deve removê-lo do cache. Mas isso não acontece. Deve haver uma maneira de liberar esse cache e fazer com que ele use o conteúdo atual doBundleCollection
vez do que ele armazenou em cache quando o pacote foi acessado pela primeira vez.
Alguma ideia de como eu faria isso?
Existe esse ResetAll
método que tem um propósito desconhecido, mas ele simplesmente quebra as coisas de qualquer maneira, então não é isso.