我正在使用ASP .NET 3.5并寻找捆绑我的一堆脚本的方法。我遇到了ScriptManager的CompositeScript元素。这是一种用于捆绑的好方法吗？它有任何后果等吗？
答案 0 :(得分：2)
优点和缺点，陷阱与其他脚本捆绑解决方案类似 - 您将首先要最小化，注意脚本的顺序，启动脚本;关闭另一个文件中任何未关闭的脚本。
一个ASP.NET特定问题是调试/开发体验。如果你组合你的脚本，在IE调试器中找到你的代码要困难得多，脚本将有一个机器生成的名称，看起来类似于其他框架生成的脚本＆amp;你的代码将被隐藏在一个更大的文件中。
所以我在代码中注册我的引用并将它们包装在ifdef DEBUG / endif和ifdef RELEASE / endif中（确保在项目属性中定义一个RELEASE，如果使用这个技巧，默认情况下不会发生）。在RELEASE版本中，我捆绑了所有脚本，DEBUG版本将文件分开。
根据Microsoft的建议，脚本捆绑最适合整个网站所需的文件。如果您有一个包含A，B，C的多页站点，并且您的用户通常只访问其中一个，那么捆绑A，B，C的文件将为用户提供2个额外的文件。我认为这是一个糟糕的微优化，因为大多数应用程序都有小的javascript文件和大型库，所以一个网站的JS捆绑价值不足以担心，除非你有很多流量。
最后，服务器端ScriptManager没有提供任何方法来延迟脚本或从客户端动态触发加载（除了在UI之后加载脚本），我使用LAB.js以后动态加载脚本...这有时候可以允许你推迟脚本直到你知道你需要它并且可能推迟加载该脚本。捆绑该脚本后，如果他们需要或不需要，将为每个用户加载它。
第2部分 另一个问题，至少在我看来，虽然你可以在web.config中启用JS文件的缓存（暂时没有时间查找语法！），你也可以使用expires头在IIS级别启用缓存，当新版本发布时，ScriptManager不会帮助您“破坏”缓存。理想情况下，脚本管理工具会让浏览器认为脚本位于随上次更新更改而更改的文件夹中，因此脚本可以在客户端缓存一年。
我希望我有关于脚本是否在服务器端缓存的信息 - 我猜他们不是。但是因为用户通常每天最多获取一次脚本 - 在我的服务器上它们似乎缓存了24小时，如果在每个请求上重新生成脚本，那就不太有趣了。
最后，如果你正在使用CDN来处理像jquery这样的事情（取决于你是公共还是内部网），那么4.0和4.5版本可以让你更容易告诉ScriptManager使用CDN和后备CDN已关闭。
答案 1 :(得分：0)
使用sumfile.js？n = {0}
其中{0}是建筑物的数字