【发布时间】：2014-04-03 12:17:57
【问题描述】：
我很难在互联网上找到任何有关如何解决此问题的信息...
我们有一个基于 ASP.NET MVC3 的网站，它使用 Cassette 进行资源捆绑。我目前正在将该网站部署到服务器上以供实时使用，但我们遇到了问题。 我有一个暂存/集成服务器，所有内容都托管在其中，运行良好。
使用相同的代码和相同的配置，当 AppPool 在新服务器上“预热”以进行直播时，盒式磁带捆绑需要几分钟才能完成。我可以说是卡带占用了时间，因为我在暂停期间运行了几次调试诊断分析，它始终显示卡带处于 CoffeeScript 捆绑过程的中间。我在 Cassette 网站上读到，如果文件太大，CoffeeScript 编译可能需要很长时间，但我们的文件很小（大约有 6 个）。
所以我的主要问题是：有什么会严重影响 Cassette 初始捆绑的性能吗？是否与用于缓存捆绑包的独立存储盒有关？
作为参考，服务器在 Windows Server 2008 R2 上运行 IIS 7.5。
奖金回合： 当事情最终加载时，我看到错误“捆绑没有资产时操作无效”。令人困惑的是，没有引用的包路径是空的。再一次，一切都在我们的登台服务器上运行，但在“实时”服务器上却不行。
非常感谢您的任何想法。
更新
设置磁带配置，以便debug=true 似乎使一切正常，包括“奖金回合”问题。我很想利用不使用像缩小这样的调试模式的好处，所以问题仍然存在。
【问题讨论】：
-
我没有完整的答案给你，但我遇到了类似的问题，所以我会抛出我所拥有的。首先，您可能需要查看offline compilation。
-
我在速度问题上苦苦挣扎并使用“调试步骤分析”的另一件事是，我注意到对
BlockingCollection的某个调用需要很长时间才能返回。最后我放弃了，寻找替代工具，然后又回到了 Cassette。当我这样做时，我重新创建了解决方案，问题就消失了。所以这不是一个解决方案，但也许您可以从我离开的地方继续并调查该阻塞集合。
标签： asp.net-mvc-3 iis cassette