ASP.NET MVC捆绑缓存。 （检测CSS文件的变化）（内部行为） [英] ASP.NET MVC Bundling cache. (Detecting css files changes) (internal behaviour)
问题描述
我已经潜入ASP.NET MVC的内部功能多（不同的原因），但仍不能涵盖所有的行为。其中一个我没有的是SUBJ。
I've been diving into ASP.NET MVC internal functionality much (different reasons), but still can not cover all the behaviour. One of those which I did not is subj.
它的工作方式如下：
如果我捆绑一些文件（CSS例如文件），的框架检测这些变化和生成新的ID 作为新的软件包（以很容易让浏览器刷新的变化），如HREF =/内容/ CSS？v = qartPE4jGe-l1U0I7kNDZPZzVTdh0kT8VBZZA_uURjI1。
if I bundle some files (css files for instance), the framework detects those changes and generates new id for the new bundle (to make it easy for browsers to refresh the changes) like href="/Content/css?v=qartPE4jGe-l1U0I7kNDZPZzVTdh0kT8VBZZA_uURjI1".
什么我其实想明白了：
-
究竟是如何架构（这可能不是MVC，但是.NET的东西）的检测到这些文件被更改（因为有的没有目录观察家活跃的（如我甚至可以更改文件时，Web服务器，如果离线）查看更改过的文件，并在系统实际检测到该文件内容的变化（我试过刚刚的重新保存文件，而无需改变其内容和捆绑数量并没有改变，以及的））？
（我认为显然是系统不能每个文件的内容进行比较，以检测其changings在每次请求进来）。
How exactly the framework (that's possibly not MVC but .NET stuff) detects that the files are changed (as there are no directory watchers active (as I can change the file even when web-server if off-line) to see the file changes live, and also the system detects actually the file content changes (I tried just to re-save files without changing their contents and the bundle number did not change as well))? (I consider that obviously the system can not compare every file content to detect its changings on every request came).
在哪里（以及如何）框架的保存有当前包ID 并如何商店previous版本（如previous捆绑仍然可用当去他们的网址）？
Where (and how) the frameworks stores current bundle id and how it stores previous versions (as previous bundles are still available when go to their urls)?
非常感谢！
推荐答案
在ASP.NET优化框架缓存在 HttpContext.Cache 捆绑响应和使用的的CacheDependency 监视变化捆绑的每个文件。这就是为什么更新文件直接无效的缓存和重新生成包。
The ASP.NET Optimization framework caches the bundle response in HttpContext.Cache and uses a CacheDependency to monitor each file in the bundle for changes. This is why updating the files directly invalidates the cache and regenerates the bundle.
该包文件名是保证了URL变化时，任何包文件被修改捆绑内容的哈希值。这个捆绑的虚拟路径用作缓存键。
The bundle file name is a hash of the bundle contents which ensures the URL changes when any of the bundle files are modified. The bundle's virtual path is used as the cache key.
从库中有关code（注意，这是略显过时，但我相信逻辑仍然是相同的）：
The relevant code from the library (note this is slightly out of date but I believe the logic is still the same):
internal BundleResponse GetBundleResponse(BundleContext context)
{
// check to see if the bundle response is in the cache
BundleResponse bundleResponse = Bundle.CacheLookup(context);
if (bundleResponse == null || context.EnableInstrumentation)
{
// if not, generate the bundle response and cache it
bundleResponse = this.GenerateBundleResponse(context);
if (context.UseServerCache)
{
this.UpdateCache(context, bundleResponse);
}
}
return bundleResponse;
}
private void UpdateCache(BundleContext context, BundleResponse response)
{
if (context.UseServerCache)
{
// create a list of all the file paths in the bundle
List<string> list = new List<string>();
list.AddRange(
from f in response.Files
select f.FullName);
list.AddRange(context.CacheDependencyDirectories);
string cacheKey = Bundle.GetCacheKey(context.BundleVirtualPath);
// insert the response into the cache with a cache dependency that monitors
// the bundle files for changes
context.HttpContext.Cache.Insert(cacheKey, response, new CacheDependency(list.ToArray()));
context.HttpContext.Response.AddCacheItemDependency(cacheKey);
this._cacheKeys.Add(cacheKey);
}
}
最后，作为老包的URL的工作，我想你会发现它们是从您的浏览器缓存返回或实际返回的最新版本捆绑，因为捆绑路径不会改变，只有版本的查询字符串。
Finally as for old bundle URLs working, I think you will find they are either returned from your browser cache or actually return the latest version of the bundle since the bundle path doesn't change, only the version query string.
这篇关于ASP.NET MVC捆绑缓存。 （检测CSS文件的变化）（内部行为）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
