Visual Studio 2010:发布缩小的 javascript 文件而不是原始文件 [英] Visual Studio 2010: Publish minified javascript files instead of the original ones

查看:18
本文介绍了Visual Studio 2010:发布缩小的 javascript 文件而不是原始文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have a Scripts folder, that includes all the .js files used in the project. Using the Ajax Minifier task, I generate .min.js files for each one. Depending on whether the application is running in debug or release mode, I include the original .js file, or the minified one.

Scripts 文件夹如下所示:

The Scripts folder looks like this:

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 文件在项目之外(虽然与原始文件在同一文件夹中),我们发布项目时不会将它们复制到目标文件夹中.

The .min.js files are outside the project (although in the same folder as the original files), and they are not copied into the destination folder when we publish the project.

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

I have no experience whatsoever using build tasks (well, apart from including the minifier task), so I would appreciate if anyone could advise me as to which would be the correct way to:

  • 当我从 Visual Studio 发布应用程序时,将 .min.js 文件复制到目标文件夹.
  • 删除/不复制原始 js 文件(这并不重要,但我宁愿不复制不会在应用中使用的文件).

谢谢,

从回复中,我发现我遗漏了一些细节,并且可能我正在寻找错误的问题解决方案.我将在问题中添加以下详细信息:

From the responses, I see that I missed some details, and that maybe I'm looking for the wrong solution to the problem. I'll add the following details to the question:

  • 如果可能,我们宁愿不在解决方案的构建过程中创建复制脚本.当然,我们考虑过,但直到现在我们都在使用 Web 部署项目,我们宁愿开始使用 VS2010 的新发布功能(应该替换这些项目),而不是手动将复制命令添加到构建任务中.
  • *.min.js 文件不包含在项目中,因为它们不能在源代码控制系统(此时为 TFS)中.它们是编译期间生成的文件,类似于在 TFS 中包含bin"文件夹(包括它会导致的问题).也许我们应该在不同的文件夹中创建 min 文件并将其视为bin"?(这可能吗?)

推荐答案

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

Edit (2012 October): ASP.NET 4.5 now includes Bundling and minification. The current version doesn't support dynamic javascript generation very well, but it's otherwise pretty usable and for instance does watch the filesystem to live changes as described below; before rolling your own compression, try that!

旧答案:

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

Rather than implement this at build time, I suggest you do so at runtime. This has a number of advantages:

  • 您可以包含关闭组合和缩小的调试参数,以便更轻松地识别错误.这也让您可以在开发和生产环境之间减少差异的情况下运行.
  • 您获得了一些灵活性.我已经两次能够通过可以直接上线的纯脚本修复来修复错误.对于简单但严重的错误,这是一个不错的选择.
  • 实施起来要简单一些 - 您已经拥有实施 http 响应的专业知识,这在此处非常适用.
  • 您可以跟踪所涉及脚本的最后修改日期,不仅可以使用它来设置适当的 ETag 等(IIS 也可以这样做),还可以设置一个很远的未来到期日期.然后,而不是链接实际的 scipt(无论是否缩小),您可以将脚本与查询字符串中的一些短标记链接 - 这样客户端就不需要检查 js 是否已更新.当它有时,页面将链接到一个无论如何需要单独请求的新"脚本文件.(这可以在构建脚本中实现,但更棘手).
  • 复杂的构建过程通常具有隐性成本.不仅运行时间更长,而且当您想要更新构建自动化工具时会发生什么?当您切换 IIS 或 Windows 版本时?当您迁移到 VS 2010 时?让新开发者跟上进度有多容易?

这是我遵循的流程的粗略概述:

This is the rough outline of the process I follow:

  1. 我指定两个目录只包含可压缩的 css 和 js.在 appdomain 实例化或此后不久通过静态构造函数,一个类找到这些目录的内容并创建一个 FileSystemWatcher 以观察变化.
  2. 所有文件都是按照文件名的顺序读取的(使用诸如00_jquery.js 10_init.js 等前缀有助于控制这里的顺序).文件名列表是为了调试目的而存储的.
  3. 所有文件通过字符串连接组合,然后由 YUI 缩小,然后通过 GZipStream 压缩.特定于版本的令牌通过最新的最后修改日期或结果的哈希计算.
  4. 压缩的结果(字节数组、文件名和特定于版本的标记)存储在静态类变量中(由 lock 保护).如果文件系统观察程序检测到更新,第 2 步将再次启动并在后台运行,直到压缩完成 - 因此锁定.
  5. 任何希望包含组合的 javascript(和/或 css)的页面都会调用共享静态变量.如果我们处于调试模式,则会为第二步中存储的每个文件名生成一个脚本(或链接)标签,否则,这会生成一个指向由自定义 IHttpHandler 处理的 Uri 的脚本(或链接)标签.所有 Uri 都在查询字符串中包含特定于版本的令牌 - IIS 静态文件处理程序和组合缩小版本的自定义 http 处理程序都忽略了这一点,但使缓存变得容易.
  6. 在自定义 IHttpHandler 中,当接收到对组合 javascript(或 css)的请求时,会设置 Content-Encoding: gzip 标头,以及未来的到期日期.然后将预压缩的字节数组通过context.Response.OutputStream直接写入http流.
  1. I specify two directories as containing only compressible css and js. At appdomain instantiation or shortly thereafter via a static constructor, a class finds the contents of those directories and creates a FileSystemWatcher to watch for changes.
  2. All files are read in order of filename (using prefixes such as 00_jquery.js 10_init.js etc. helps control order here). The list of filenames is stored for debug purposes.
  3. All files are combined via string concatenation, then minified by YUI, then compressed via GZipStream. A version specific token is computed either by newest last-modified date or by the hash of the result.
  4. The result of the compression (byte array, filenames, and version-specific token) is stored in a static class variable (protected by a lock). If the file system watcher detects an update, step 2 starts again and runs in the background until the compression completes - hence the locking.
  5. Any page wishing to include the combined javascript (and/or css) calls the shared static variable. If we're in debug mode, that generates a script (or link) tag for each filename as stored in step two, otherwise, this generates a single script (or link) tag to a Uri that's handled by a custom IHttpHandler. All Uri's include the version-specific token in the querystring - this is ignored both by the IIS static file handler and the custom http handler for the combined minified version, but makes caching easy.
  6. In a custom IHttpHandler, when a request for the combined javascript (or css) is received, the Content-Encoding: gzip header is set, and a far-future Expiry date. Then the precompressed byte array is written directly to the http stream via context.Response.OutputStream.

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

Using that approach, you won't need to fiddle with web.config options whenever you add or remove a script file; you can update scripts while the app is running and clients will request these on the very next page view - but you still will get optimal cache behavior since browsers won't even send an If-Not-Modified request due to the expiry header. Usually, compressing scripts should take a second or so and the compressed result should be so small that the memory overhead of the static variable is negligible (at most a few 100 KB for a truly large amount of scripting / css).

这篇关于Visual Studio 2010:发布缩小的 javascript 文件而不是原始文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆