То, что "этот волшебный guid / string" является хэшем содержимого объединенного файла.
Вы можете проверить это с помощью следующего рабочего процесса, который предполагает, что у вас есть mybundle.css
.Если вы используете Fiddler для отслеживания трафика, вы увидите, что он запрашивает что-то с хешем, например
http://localhost:20206/mybundle.css?v=-6520265193368900210
Теперь, «дотроньтесь» до одного из файлов в пакете столько, сколько вы хотите, без фактического изменения содержимого,Файл более новый (LastModified / LastWrite более поздний), но хэш остается постоянным, поскольку он вычисляется из того же объединенного содержимого.Вы даже можете добавить пробелы в файл, так как они будут сведены к минимуму.
http://localhost:20206/mybundle.css?v=-6520265193368900210
Затем внесите изменения.Возможно, установите границу 2px вместо 1px.Хеш теперь изменится, поскольку содержимое, передающее хеш, изменилось.
http://localhost:20206/mybundle.css?v=-4725541136976015445
Наконец, установите границу обратно на то, что было (в приведенном выше примере обратно на 1px).«Волшебная нить» на самом деле вовсе не случайна и не волшебна.Вместо этого он возвращается к соответствующему одностороннему хешу, вычисленному из содержимого.
http://localhost:20206/mybundle.css?v=-6520265193368900210
Теперь вы можете быть спокойны, что хеш будет обновляться только тогда, когда это необходимо, без ручного вмешательства.
Что касается другой части вашего вопроса,
, когда этот CSS / JS изменяется в базе данных, этот пакет нужно «обновить», чтобы содержимое этих файлов было перечитано вна связку.
Я думаю, что мы просто изменим мышление.Вместо обновления пакета для запуска повторного чтения, мы обновляем файлы для запуска обновления.Когда ASP.NET увидит изменение файла (ов), он рекомбинирует содержимое и обновит хеш.