MicrosoftAjax.js 没有被缩小有什么原因吗？答案

【问题标题】：Is there any reason why MicrosoftAjax.js is not minified?MicrosoftAjax.js 没有被缩小有什么原因吗？
【发布时间】：2010-11-05 12:39:03
【问题描述】：

我使用 YuiCompressor 压缩了我自己的 JS，但是 MicrosoftAjax.js 没有缩小有什么原因吗？或者是否有一些设置说运行它的压缩版本（如果有压缩版本）。还是我需要自己反编译并缩小脚本资源？

【问题讨论】：

从我得到的回复来看，似乎没有开箱即用的 MicrosoftAjax.js 的缩小/压缩版本。所以看起来DIY是我在我选择的答案中提到的方式。正如我向 Josh 提到的，在 ASP.NET 3.5 中，您现在可以组合脚本 msdn.microsoft.com/en-us/library/cc488552.aspx。我们还没有迁移到 3.5，但是当我们这样做时，我会检查一下。我读过关于它的混合评论。同样，我前段时间在项目中添加了jQuery，所以我正在慢慢地对所有可以被jQuerified的东西进行jQuerifying。
我上面的评论不再正确。 Dave Ward 的答案是好的，所以不要 DIY。

标签： javascript asp.net-ajax minify

【解决方案1】：

我对这些误导性的答案感到惊讶。

ASP.NET AJAX 始终提供 MicrosoftAjax.js 的调试和压缩版本。 web.config 的调试设置和ScriptManager's ScriptMode property 控制引用哪个脚本的组合。

此外，您可以使用the "retail" setting 强制压缩脚本。

【讨论】：

感谢这个戴夫。很高兴知道。
太棒了，我不知道“零售”设置，我们公司有在生产中部署东西的习惯，仍然处于调试模式等。

【解决方案2】：

System.Web.Extensions 中的所有脚本都被缩小了——每个都有两个版本，正如 Dave Ward 的出色回答所指出的那样。当 web.config 处于调试模式时，ScriptManager 默认将使用调试版本。翻转它以使用零售设置或 debug="false" 发布，然后查看脚本。

此外，通过 WebResourceHandler 或 ScriptResourceHandler 提供的脚本实际上是缓存的。它们以最好的方式被缓存——永远，所以它们在以后的访问中甚至不需要 301。查询字符串保持原样，因为它包含加密数据。它是加密的，因为它包含有关脚本资源的信息，包括程序集名称，还因为它可以防止缓存泛滥攻击。

不在这里寻找代表，只是想提供更多细节。

【讨论】：

很高兴了解正在缓存的 WebResourceHandler 或 ScriptResourceHandler。因此，我假设当您进行更改和重新部署时，它们会再次缓存，但作为不同的文件，因为加密的查询字符串已更改？
是的。对资源的任何更改都会更改查询字符串，从而产生一个新缓存的项目。我也没有提到脚本也是 gzip 压缩的。

【解决方案3】：

见http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx，你需要

enableScriptMinification="true"

选项并将 MicrosoftAjax.js 添加到列表中

【讨论】：

我以前读过这篇文章，但感谢您在这里发布。我一直在寻找的是来自 Microsoft Ajax 的开箱即用的解决方案。看起来 DIY 是一种方法。

【解决方案4】：

你更喜欢哪个：

MicrosoftAjax.js 已压缩，已被混淆。
MicrosoftAjax.js 未压缩并打开，因此您可以自己阅读和理解它。

【讨论】：

虽然同时拥有这两个版本很简单，而且也相当有用，但如果您打算采取简单的方法，您应该提供未压缩的版本。 +1，因为这不值得投反对票。
@Neil N. 我同意，为什么不两者兼而有之？开发时使用未压缩并在 prod 中使用缩小/混淆版本。

【解决方案5】：

编辑：在我的辩护中，在撰写此答案时，我没有使用 .NET 3.5 的经验；我现在意识到他们在这方面做出了一些急需的改进。

显然，MS 并不认为 JavaScript 文件大小很重要（这太疯狂了）。此外，根据我使用 MS Ajax 的经验，他们还在标记中注入了几个 SCRIPT 标记（有时超过 10 个）。这些标签从 WebResource.axd 处理程序中引入脚本。因此，必须发出十个或更多请求才能获得运行页面所需的 Javascript！更荒谬的是，他们在处理程序 URL 上添加了一个疯狂的查询字符串，这可能会阻止脚本被浏览器缓存。

这种疯狂足以让我完全放弃 MS Ajax 并切换到 jQuery，这是一个更好的库，尤其是，因为 Visual Studio now has Intellisense for jQuery。

【讨论】：

不确定，请投我一票，因为我同意你对 ASP.NET Ajax 的看法。
我也被否决了——也许我们有一个 MS 职员在 SO？ :) 我确实希望反对者能解释为什么他们这样投票......
Josh，在 ASP.NET 3.5 中，它们现在允许您组合客户端脚本，请参阅将客户端脚本组合成一个组合脚本，msdn.microsoft.com/en-us/library/cc488552.aspx。有人试过吗？
很高兴知道。没试过，因为我们还没有升级我们的框架。
更正：“MS 不觉得 Javascript 文件大小很重要”：不正确：他们提供了每个脚本的缩小版本，在发布模式下自动输出。 “必须提出十个或更多请求”：这是一个极端情况，我们在一个大型应用程序中只有 1 个，甚至没有尝试。 “这可能会阻止脚本被缓存”：这不会阻止浏览器缓存，尽管一些较旧的代理服务器可能无法正确缓存。在 3.5 中，脚本组合器将当前页面的所有脚本推送到一个 url，一个 cached 响应中。这包括我们所有的 jQuery。

【解决方案6】：

我只能假设它保持原样以便于理解，并且正如你已经暗示的那样，我知道你不能自己压缩它的原因，毕竟它只是 JavaScript - 虽然 MS 可能就像你相信的那样，他们不会在上面撒上神奇的精灵粉来让它变得与众不同！ :)

[让我们面对现实吧； MS 从不害怕他们代码的大小，不是吗？]

【讨论】：