Visual Studio 2010: публиковать уменьшенные файлы javascript вместо оригинальных

Правка (октябрь 2012 г.): ASP.NET 4.5 теперь включает объединение и минификацию . Текущая версия не очень хорошо поддерживает динамическую генерацию javascript, но в остальном она довольно удобна и, например, отслеживает изменения файловой системы, как описано ниже; прежде чем накатывать собственное сжатие, попробуйте это!

Старый ответ:

Вместо того, чтобы реализовывать это во время сборки, я предлагаю вам сделать это во время выполнения. Это дает ряд преимуществ:

• Вы можете включить параметры отладки, которые отключают комбинирование и минификацию, чтобы упростить идентификацию ошибок. Это также позволяет работать с меньшими различиями между средой разработки и производственной средой.
• Вы получаете некоторую гибкость. Мне дважды удавалось исправлять ошибки с помощью исправления, предназначенного только для сценариев, которое может быть запущено напрямую. Это хороший вариант для простых, но критических ошибок.
• Реализовать это немного проще - у вас уже есть опыт в реализации HTTP-ответов, что здесь хорошо применимо.
• Вы можете отслеживать дату последнего изменения задействованных скриптов и не только использовать ее для установки соответствующих ETags и прочего (что IIS тоже может делать), но и устанавливать дату истечения срока действия в далеком будущем. Затем, вместо того, чтобы связывать фактический скрипт (минимизированный или нет), вы можете связать скрипт с некоторым коротким токеном в строке запроса - таким образом клиентам не нужно будет проверять, обновился ли js. Когда это произойдет, страницы будут ссылаться на «новый» файл сценария, который в любом случае нужно запрашивать отдельно. (Это можно сделать в сценариях сборки, но сложнее).
• Сложный процесс сборки часто имеет скрытые затраты.Это не только занимает больше времени, но и что происходит, когда вы хотите обновить свой инструмент автоматизации сборки? Когда вы переключаете версию IIS или Windows? Когда вы переходите на VS 2010? Насколько легко научить новых разработчиков быстро освоиться?

Это приблизительный набросок процесса, которому я следую:

1. Я определяю два каталога как содержащие только сжимаемые css и js. При создании экземпляра домена приложения или вскоре после этого с помощью статического конструктора класс находит содержимое этих каталогов и создает FileSystemWatcher для отслеживания изменений.
2. Все файлы читаются в порядке имен файлов (использование таких префиксов, как 00_jquery.js 10_init.js и т. Д., Помогает контролировать порядок здесь). Список имен файлов сохраняется для целей отладки.
3. Все файлы объединяются путем конкатенации строк, затем уменьшаются с помощью YUI, затем сжимаются с помощью GZipStream . Маркер версии вычисляется либо по дате последнего изменения, либо по хешу результата.
4. Результат сжатия (байтовый массив, имена файлов и токен, зависящий от версии) сохраняется в статической переменной класса (защищенной блокировкой ). Если наблюдатель файловой системы обнаруживает обновление, шаг 2 запускается снова и выполняется в фоновом режиме до завершения сжатия - отсюда и блокировка.
5. Любая страница, желающая включить комбинированный JavaScript (и / или CSS), вызывает общую статическую переменную.Если мы находимся в режиме отладки, он генерирует тег сценария (или ссылки) для каждого имени файла, сохраненный на шаге два, в противном случае создается один тег сценария (или ссылки) для Uri, который обрабатывается пользовательским IHttpHandler . Все Uri включают токен версии в строку запроса - он игнорируется как обработчиком статических файлов IIS, так и настраиваемым обработчиком http для объединенной минифицированной версии, но упрощает кеширование.
6. В настраиваемом IHttpHandler при получении запроса на объединенный javascript (или css) устанавливается заголовок Content-Encoding: gzip и устанавливается дата истечения срока действия в далеком будущем. Затем предварительно сжатый байтовый массив записывается непосредственно в поток http через context.Response.OutputStream .

При таком подходе вам не придется возиться с параметрами web.config всякий раз, когда вы добавляете или удаляете файл сценария; вы можете обновлять сценарии во время работы приложения, и клиенты будут запрашивать их при следующем просмотре страницы, но вы все равно получите оптимальное поведение кеша, поскольку браузеры даже не отправят запрос If-Not-Modified из-за заголовка срока действия. Обычно сжатие сценариев должно занимать секунду или около того, а сжатый результат должен быть настолько маленьким, чтобы накладные расходы на память статической переменной были незначительными (максимум несколько 100 КБ для действительно большого количества сценариев / CSS).