我的sharepoint css有一个奇怪的情况。
它作为.wsp解决方案的一部分进行部署，直到现在一切都很好。
它部署的服务器场也有几个Webfront端和一个应用服务器和SQL框。
症状是，如果我部署解决方案，然后使用webbrowser查看它没有样式的页面，如果我直接访问.css，我会看到.css的前100个字节。
但是，如果我进入sharepoint设计器并查看该文件它看起来很好，如果我检查并发布它（自定义文件但实际上没有更改任何内容），那么网站工作正常和css下载完全。
服务器上有一些相当复杂的缓存基于磁盘和对象缓存。据我所知，我已经清除了这些（并且无论如何应该清除它们......不应该吗？）
我已使用此工具清除整个服务器场中的blobcache http://blobcachefarmflush.codeplex.com/
答案 0 :(得分：5)
你所描述的问题是我以前遇到的问题。让我分享一下我所知道的，我怀疑的内容，以及我如何对你的场景进行故障排除。
首先，听起来您怀疑缓存是潜在的问题来源。对于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并调整文件模式以从中删除 CSS ＆lt; BlobCache＆gt; 元素中的文件类型列表，然后重新启动IIS（或至少回收应用程序池）。
根据经验，另一种可能性是你看到的不是BLOB缓存异常。对我来说，关键的观察结果是你观察到CSS样式表的直接请求只返回前100个字节左右。
您是否有任何机会在WFE与您（呼叫者）之间拥有任何智能网络硬件（即入侵检测硬件或可能正在执行应用程序/第7层过滤的任何内容）？入侵检测和IPS系统是您所看到的许多类型问题的根源，只要我看到您所描述的“古怪”行为，它们就是我的第一站。对于我的一个客户，由于介入的Juniper防火墙和主动IPS，我看到了满足您的描述（CSS和JS文件被截断）的问题。关闭IPS（测试）立即清理。之后，网络团队寻求Juniper的更新来纠正问题，以确保IPS能够保持活跃状态。
尝试关闭BLOB缓存（或从文件模式中删除CSS扩展）以查看是否会产生影响。如果没有，请与您的网络团队联系，以了解回复给您的响应流是否发生了什么。那是我开始的地方;希望，这两件事中的一件能帮到你。
小方面注意：如果您有空闲时间并且愿意接受它，我想了解您从CodePlex下载的BlobCacheFarmFlush解决方案的体验。我写了它，我很乐意听到你的想法 - 好的或坏的： - ）