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

У меня есть папка Scripts, в которую входят все файлы .js, используемые в проекте. Используя задачу Ajax Minifier, я генерирую файлы .min.js для каждого. В зависимости от того, работает приложение в режиме отладки или выпуска, я включаю исходный файл .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 находятся за пределами проекта (хотя и находятся в той же папке, что и исходные файлы), и они не копируются в целевую папку, когда мы публикуем проект.

У меня нет опыта работы с задачами сборки (ну, кроме включения задачи минификатора), поэтому я был бы признателен, если бы кто-нибудь посоветовал мне, какой будет правильный путь:

  • Скопируйте файлы .min.js в папку назначения при публикации приложения из Visual Studio.
  • Удалить / не копировать исходные файлы js (это не существенно, но я бы не стал копировать файлы, которые не будут использоваться в приложении).

Спасибо

Редактировать: Из ответов я вижу, что упустил некоторые детали и, возможно, я ищу неправильное решение проблемы. Я добавлю следующие детали к вопросу:

  • Если возможно, мы не будем создавать сценарии копирования в процессе сборки решения. Конечно, мы рассмотрели это, но мы использовали проекты веб-развертывания до сих пор, и мы скорее начали бы использовать новую функцию публикации VS2010 (которая должна заменить эти проекты), чем вручную добавлять команды копирования в задачу сборки.
  • Файлы * .min.js не включены в проект, поскольку они не могут находиться в системе управления исходным кодом (TFS на данный момент). Это файлы, сгенерированные во время компиляции, и это было бы похоже на включение папки 'bin' в TFS (включая проблемы, которые это может вызвать). Может быть, нам следует создать файлы min в другой папке и рассматривать их как «bin»? (Это вообще возможно?)

Ответы [ 5 ]

20 голосов
/ 21 апреля 2010

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

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

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

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

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

  1. Я указываю две директории как содержащие только сжимаемые css и js. При создании экземпляра домена приложения или вскоре после этого через статический конструктор класс находит содержимое этих каталогов и создает FileSystemWatcher для отслеживания изменений.
  2. Все файлы читаются в порядке имени файла (использование префиксов, таких как 00_jquery.js 10_init.js и т. Д., Помогает контролировать порядок здесь). Список имен файлов хранится в целях отладки.
  3. Все файлы объединяются с помощью конкатенации строк, затем минимизируются с помощью YUI, затем сжимаются с помощью GZipStream. Токен, зависящий от версии, вычисляется либо по последней дате последнего изменения, либо по хэшу результата.
  4. Результат сжатия (байтовый массив, имена файлов и маркер, зависящий от версии) сохраняется в переменной статического класса (защищенной lock). Если наблюдатель файловой системы обнаруживает обновление, шаг 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).

7 голосов
/ 17 апреля 2010

Если вы хотите минимизировать Javascript через Visual Studio, вы начнете: http://encosia.com/2009/05/20/automatically-minify-and-combine-javascript-in-visual-studio/

В противном случае, я бы порекомендовал инструмент, который может автоматически комбинировать и минимизировать Javascript. Два инструмента, на которые я посмотрел: Джастин Этередж Пакет и Combres . Я использую Bundler в своем текущем проекте, а один из моих коллег по работе использует Combres. Bundler немного проще в использовании, но он делает меньше, чем Combres. При использовании Bundler, если отладка отключена в web.config, она не минимизируется и не объединяется, что означает, что вы можете отлаживать javascript в вашей среде разработки.

P.S. Bundler был переименован в SquishIt.

3 голосов
/ 17 апреля 2010

Возможно, вы захотите взглянуть на Build Events , с помощью которого вы можете указать командную строку для выполнения пост-сборки. Ваш вопрос, кроме того, похож на эти вопросы .

Для фактического копирования вы можете просто использовать команду COPY .

2 голосов
/ 18 апреля 2010

Я не совсем уверен, будет ли этот подход полезен в этой ситуации, но я мог себе это представить ... Вы можете изменить файлы csproj, например: влияет на то, какие файлы должны быть включены в определенный тип сборки.

С определенным типом я имею в виду Configuration Manager.

Отладка и выпуск по умолчанию, но ничто не мешает вам делать новые. На основе выбранной конфигурации вы можете иметь разные файлы, являющиеся частью конфигурации, и я полагаю, что вы можете опубликовать разные файлы таким образом. Я описал эту стратегию в своем блоге здесь: http://realfiction.net/go/130

1 голос
/ 19 апреля 2010

Эта статья о «Автоматическом уменьшении, объединении, сжатии и кэшировании файлов * .js и * .css в вашем проекте ASP.NET» может помочь вам

http://www.codeproject.com/KB/aspnet/CssAndJavaScriptOptimizer.aspx?display=Print

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...