javascript - Visual Studio 2010 : Publish minified javascript files instead of the original ones

Question

我有一个 Scripts 文件夹，其中包含项目中使用的所有 .js 文件。使用 Ajax Minifier 任务，我为每个文件生成 .min.js 文件。
根据应用程序是在 Debug模式还是 Release模式下运行，我包含原始 .js 文件或缩小的文件。

Scripts 文件夹如下所示:

Scripts/script1.js
Scripts/script1.min.js   // Outside the project, generated automatically on build
Scripts/script2.js
Scripts/script2.min.js   // Outside the project, generated automatically on build

.min.js 文件在项目之外(尽管与原始文件在同一文件夹中)，并且在我们发布项目时不会将它们复制到目标文件夹中。

我没有任何使用构建任务的经验(好吧，除了包括 minifier 任务)，所以如果有人能告诉我哪种是正确的方法，我将不胜感激:

当我从 Visual Studio 发布应用程序时，将 .min.js 文件复制到目标文件夹。

删除/不复制原始 js 文件(这并不重要，但我宁愿不复制不会在应用程序中使用的文件)。

谢谢，

编辑:从回复中，我发现我遗漏了一些细节，也许我正在寻找错误的解决方案。我将在问题中添加以下详细信息:

如果可能，我们宁愿不在解决方案的构建过程中创建复制脚本。当然，我们考虑过，但直到现在我们都在使用 Web 部署项目，我们宁愿开始使用 VS2010 的新发布功能(应该替换这些项目)，而不是手动将复制命令添加到构建任务中。

*.min.js 文件不包含在项目中，因为它们不能在源代码控制系统(此时为 TFS)中。它们是编译期间生成的文件，类似于在 TFS 中包含“bin”文件夹(包括它会导致的问题)。也许我们应该在不同的文件夹中创建 min 文件并将其视为“bin”？ (这甚至可能吗？)

Answer 1

编辑(2012 年 10 月): ASP.NET 4.5 现在包括 Bundling and minification .当前版本不能很好地支持动态 javascript 生成，但它在其他方面非常有用，例如确实观察文件系统的实时变化，如下所述；在滚动您自己的压缩之前，请尝试一下!

旧答案:

我建议您在运行时执行此操作，而不是在构建时执行此操作。这有许多优点:

您可以包含关闭组合和缩小的调试参数，以便更轻松地识别错误。这也使您可以在开发环境和生产环境之间的差异较小的情况下运行。

你获得了一些灵活性。我已经两次能够通过可以直接上线的纯脚本修复来修复错误。对于简单但关键的错误，这是一个不错的选择。

实现起来要简单得多 - 您已经拥有实现 http 响应的专业知识，这在这里非常适用。

您可以跟踪所涉及脚本的最后修改日期，不仅可以使用它来设置适当的 ETag 等(IIS 也可以这样做)，还可以设置一个很远的 future 到期日期。然后，而不是链接实际的 scipt(无论是否缩小)，您可以将脚本与查询字符串中的一些短标记链接 - 这样客户端就不需要检查 js 是否已更新。当它有时，页面将链接到一个"new"脚本文件，无论如何都需要单独请求。 (这可以在构建脚本中完成，但更棘手)。

复杂的构建过程通常有隐藏的成本。不仅运行时间更长，而且当您想要更新构建自动化工具时会发生什么？当您切换 IIS 或 Windows 版本时？当您迁移到 VS 2010 时？让新开发人员跟上进度有多容易？

这是我遵循的过程的粗略轮廓:

我指定两个目录只包含可压缩的 css 和 js。在 appdomain 实例化或此后不久通过静态构造函数，一个类找到这些目录的内容并创建一个 FileSystemWatcher 观察变化。

所有文件都按文件名的顺序读取(使用前缀如 00_jquery.js 10_init.js 等有助于控制这里的顺序)。文件名列表存储用于调试目的。

所有文件通过字符串连接组合，然后通过 YUI 缩小，然后通过 GZipStream 压缩.特定于版本的 token 由最新的最后修改日期或结果的散列计算。

压缩的结果(字节数组、文件名和特定于版本的标记)存储在静态类变量中(受 lock 保护)。如果文件系统观察程序检测到更新，则第 2 步再次开始并在后台运行，直到压缩完成 - 因此锁定。

任何希望包含组合的 javascript(和/或 css)的页面都调用共享静态变量。如果我们处于 Debug模式，它会为第二步中存储的每个文件名生成一个脚本(或链接)标签，否则，这会生成一个指向由自定义 IHttpHandler 处理的 Uri 的单个脚本(或链接)标签。 .所有 Uri 都在查询字符串中包含特定于版本的 token - IIS 静态文件处理程序和组合缩小版本的自定义 http 处理程序都忽略了这一点，但使缓存变得容易。

在自定义 IHttpHandler 中，当接收到对组合 javascript(或 css)的请求时，会设置 Content-Encoding: gzip header ，以及 future 的到期日期。然后通过context.Response.OutputStream将预压缩的字节数组直接写入http流中.

使用这种方法，无论何时添加或删除脚本文件，您都不需要摆弄 web.config 选项；您可以在应用程序运行时更新脚本，客户端将在下一个页面 View 中请求这些脚本 - 但您仍将获得最佳缓存行为，因为浏览器甚至不会由于过期 header 而发送 If-Not-Modified 请求。通常，压缩脚本应该需要一秒钟左右，并且压缩结果应该很小，以至于静态变量的内存开销可以忽略不计(对于真正大量的脚本/css 最多只有几百 100 KB)。