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

问题描述

我有一个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文件复制到目标文件夹。


• 删除/不复制t他原来的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的新发布功能（应该替换这些项目）而不是手动将复制命令添加到构建任务。 / li>
  
• * .min.js文件不包含在项目中，因为它们不能在Source控制系统中（此时为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!

旧答案：

Old answer:

我建议你在运行时这样做，而不是在构建时实现它。这有许多优点：

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

• 您可以包含关闭组合和缩小的调试参数，以便更容易地识别错误。这也使您可以在开发和生产环境之间减少差异。


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


• 实现起来相当简单 - 你已经具备了实现http响应的专业知识，这在这里很适用。


• 您可以跟踪所涉及脚本的上次修改日期，而不仅仅是使用它来设置适当的ETag和whatnot（IIS也可以做什么），而是设置远期到期日期。然后，您可以将脚本与查询字符串中的一些短标记链接，而不是链接实际的scipt（无论是否缩小） - 这样客户端就不需要检查js是否已更新。如果有，页面将链接到新脚本文件，无论如何都需要单独请求。 （这可以在构建脚本中进行，但更棘手）。


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

• You can include debugging parameters that turn off the combining and minification to permit easier identification of errors. This also allows you to run with less difference between development and production environment.
• You gain some flexibility. I've twice been able to fix errors via a script-only fix that can go live directly. For simple but critical errors that's a nice option.
• It's quite a bit simpler to implement - you already have the expertise in implementing http responses, which applies nicely here.
• You can track the last-modified date of the scripts involved, and not only use that to set the appropriate ETags and whatnot (which IIS can do too), but rather set a far-future expiry date. Then, rather than linking the actual scipt (whether minified or not), you can link the script with some short token in the querystring - that way clients don't need to check whether the js has updated. When it has, the pages will link to a "new" script file that needs to be separately requested anyhow. (This is possible to do in build scripts, but trickier).
• A complex build process often has hidden costs. Not only does it take longer to run, but what happens when you want to update your build automation tool? When you switch IIS or windows versions? When you migrate to VS 2010? How easy is it to bring new developers up to speed?

这是我遵循的流程的大致轮廓：

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）调用共享的静态变量。如果我们处于调试模式，则会为第二步中存储的每个文件名生成一个脚本（或链接）标记，否则，这会生成一个由自定义<$ c $处理的Uri的单个脚本（或链接）标记。 C>的IHttpHandler 。所有Uri都包含查询字符串中特定于版本的令牌 - IIS静态文件处理程序和组合缩小版本的自定义http处理程序都会忽略它，但会使缓存变得容易。


6. In自定义IHttpHandler，当收到组合javascript（或css）的请求时，将设置Content-Encoding：gzip标头，以及远期的Expiry日期。然后通过 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，最多只需要几百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屋！