你能解决我奇怪的 Sharepoint CSS 缓存/自定义问题吗？
我的 sharepoint css 遇到了奇怪的情况。
它作为 .wsp 解决方案的一部分进行部署，到目前为止一切都很好。
它部署的服务器场也有几个 Web 前端和一个应用程序服务器和 SQL 框。
症状是，如果我部署解决方案，然后使用网络浏览器查看页面，它没有样式，如果我直接访问 .css，我会看到 .css 的前 100 个左右字节。
但是，如果我进入 sharepoint 设计器并查看该文件，它看起来很好，如果我检查并发布它（自定义文件但实际上不更改其中的任何内容），则网站工作正常并且 css 下载完全。
服务器上有一些相当复杂的缓存基于磁盘和对象缓存。据我所知，我已经清除了这些（并且 issreset 应该清除它们......不应该吗？）
我已经使用此工具从整个场中清除了 blobcache http://blobcachefarmflush.codeplex.com/
I have a weird situation with my sharepoint css.
It is deployed as part of a .wsp solution and up until now everything has been fine.
The farm it deploys too has a couple of webfront ends and a single apps server and SQL box.
The symptom is that if I deploy the solution, then use a webbrowser to view the page it has no styles, and if I access the .css directly I see the first 100 or so bytes of the .css.
However if I go into sharepoint designer and look at the file it is looks fine, and if I check it out and publish it (customising the file but not actually changing anything in it) then the website works fine and the css downloads completely.
There is some fairly complex caching on the servers Disk based and object caches. as far as I can tell I have cleared these (and an issreset should clear them anyway... shouldn't it?)
I have used this tool to clear the blobcache from the whole farm http://blobcachefarmflush.codeplex.com/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你描述的问题是我以前遇到过的。让我分享我所知道的、我怀疑的以及我将如何对您的情况进行故障排除。
首先，听起来您怀疑缓存是潜在的问题根源。对于 MOSS 发布功能集，实际上运行着三种不同的缓存机制：对象缓存、BLOB 缓存和页面输出缓存。假设使用默认设置打开，唯一应该发挥作用的机制是 BLOB 缓存。对象缓存和页面输出缓存都不应该像您一样接触独立的样式表。
您已尝试使用场级 BLOB 缓存刷新功能刷新缓存，这将指示 MOSS 转储所有 BLOB 缓存数据。您可以通过检查文件系统来验证这一点，以确保刷新后仅保留三个 .bin 文件夹。
对于有关 IISRESET 的具体问题：不，IISRESET 实际上不会清除 BLOB 缓存。 BLOB 缓存的内容在为 Web 应用程序提供服务的应用程序池的生命周期之外仍然存在。您要么需要使用一项功能来清除缓存（就像您以前所做的那样），要么执行手动文件删除。我不推荐后者，除非您绝对没有其他行动方案。如果您选择手动尝试，请确保在从文件系统中删除文件之前关闭 W3SVC 服务。如果不这样做，实际的文件删除过程可能会陷入缓存重新填充的竞争状态并导致损坏。当您删除已停止的 W3SVC 的文件后，您可以再次启动 W3SVC。
有关 BLOB 缓存的内部结构及其操作方式的更多信息，我将向您推荐我的一篇博客文章：http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound- as-the-flush-comes/
要查看 BLOB 缓存是否是您所看到的行为的一个因素，您可以修改 Web 应用程序的 web.config 并调整文件模式以删除从
根据经验，另一种可能性是您看到的不是 BLOB 缓存异常。对我来说，关键的观察结果是您观察到对 CSS 样式表的直接请求仅返回前 100 个字节左右。
您是否有可能在 WFE 和您（呼叫者）之间拥有任何智能网络硬件（即入侵检测硬件或任何可能执行应用程序/第 7 层过滤的设备）？入侵检测和 IPS 系统是您所看到的许多类型问题的根源，每当我看到您所描述的“奇怪”行为时，它们都是我的第一站之一。就我的一位客户而言，我发现由于具有活动 IPS 的 Juniper 防火墙介入而导致出现符合您描述的问题（CSS 和 JS 文件被截断）。关闭 IPS（进行测试）立即解决了问题。此后，网络团队寻求瞻博网络的更新来纠正该问题，以确保 IPS 能够保持活动状态。
尝试关闭 BLOB 缓存（或从文件模式中删除 CSS 扩展），看看是否有影响。如果没有，请与您的网络团队联系，看看返回给您的响应流是否出现问题。这就是我要开始的地方；希望这两件事中的一件能帮到你。
小旁注：如果您有空闲时间并且愿意，我想听听您使用从 CodePlex 获取的 BlobCacheFarmFlush 解决方案的体验。我创作了它，我很想听听您的想法 - 好还是坏:-)
The problem you're describing is one I've encountered before. Let me share what I know, what I suspect, and how I'd go about troubleshooting your scenario.
First off, it sounds like you suspect caching as a potential problem source. In the case of the MOSS publishing feature set, you really have three different cache mechanisms in operation: the object cache, the BLOB cache, and the page output cache. The only mechanism that should be in-play, assuming it's turned on with default settings, is the BLOB cache. Neither the object cache nor the page output cache should be touching stand-alone stylesheets like you have.
You've tried flushing the cache the flush using the farm-level BLOB cache flush feature, and that will instruct MOSS to dump all BLOB cache data. You can verify this by reviewing the file system to ensure that only the three .bin folders remain following a flush.
To your specific question regarding an IISRESET: no, and IISRESET actually won't clear the BLOB cache. The contents of the BLOB cache persist beyond the life of the application pool servicing the web application. You either need to use a feature to clear out the cache (as you have been), or perform a manual file delete. I don't recommend the latter unless you absolutely have no other course of action. If you do elect to go the manual route to try it, ensure that you shutdown the W3SVC service before deleting files out of the file system. If you don't, the actual file deletion process can get into a race condition with cache repopulation and lead to corruption. After you've deleted files with a stopped W3SVC, you can start the W3SVC back up again.
For more information on the internals of the BLOB cache and how it operates, I'll point you to a blog article of mine: http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/
To see if the BLOB cache is a factor in the behavior you're seeing, you can modify the web.config for your web application(s) and adjust the file pattern to remove CSS from the list of file types in the <BlobCache> element and then restart IIS (or at least recycle the app pool).
Another possibility, based on experience, is that you're seeing something other than BLOB cache abnormalities. The key observation for me comes in the form of you observing that a direct request for the CSS stylesheet returns only the first 100 bytes or so.
Do you, by any chance, have any intelligent network hardware (that is, intrusion detection hardware or anything that might be performing application/layer-7 filtering) between the WFE and you, the caller? Intrusion detection and IPS systems are the source of many of the types of problems you're seeing, and they're one of my first stops whenever I see "oddball" behavior like you're describing. In the case of one of my clients, I saw a problem meeting your description (CSS and JS files getting truncated) due to an intervening Juniper firewall with active IPS. Turning off IPS (to test) cleared things up immediately. After that, the networking team sought an update from Juniper to correct the issue to ensure that IPS could remain active.
Try turning off BLOB caching (or removing the CSS extension from the file pattern) to see if that makes a difference. If not, talk to your network team to see if something is happening to the response stream coming back to you. That's where I'd start; hopefully, one of those two things will do the trick for you.
Small side note: if you have a free moment and are up to it, I'd like to hear about your experience with the BlobCacheFarmFlush solution you pulled down from CodePlex. I authored it, and I'd love to hear your thoughts -- good or bad :-)