В MSBuild сократите & конкатенацию на JavaScript, содержание хэш в именем
До этого момента я использовал MS Ajax Minifier для сжатия и объединения моих CSS и JS. Мои серверы устанавливают очень далекие будущие заголовки expires, поэтому мне нужна стратегия истечения срока действия кэша. В настоящее время я вручную версирую эти элементы, изменяя имя файла, чтобы они истекали в каждом выпуске.
Я хотел бы несколько автоматизировать это, в частности, добавив хэш содержимого файла к сжатому имени файла. Бонусные очки, если мы сможем затем обновить некоторый конфигурационный XML (который существует в другой проект) файл с этим обновленным именем
Мы используем TFS build server, поэтому я предполагаю, что это должно быть обернуто в задачу MSBuild? Или я могу просто запустить его как этап проекта до/после сборки?
Был бы очень признателен, если бы кто-то обладал какими-либо знаниями в этой области, которыми они с радостью поделятся.
Спасибо
2 ответа:
Конечно, вы могли бы сделать все это из MSBuild:
- Создайте своифайлы Манифеста Ajax Minifier . Я бы сохранил их статичными и версионными.
Создайте один MSBuild скрипт содержащий:
1 - Ajax Minifier Manifest Task для выполнения раздавливания и комбинирования.
2 - задача хеширования . Как вы можете видеть, это код c#. Измените код для чтения выходной папки, установленной на шаге '1', и измените имена файлов, добавив вычисленные хэш каждому из них.
Импортируйте созданный сценарий msbuild в свои проекты или в основной сценарий сборки, если он у вас есть.
Рассматривали ли вы функцию связывания и минификации в системе.Сеть.Оптимизация?
Http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Это должно сделать все, что вам нужно, без хлопот по обслуживанию msbuild.
Он не затрагивает исходные файлы и изменяет хэш пакета для каждой сборки. Кроме того, он может быть программно отключен на сайте live, чтобы разрешить отладку css и js на сайтах live с сохранением всех исходных имен файлов и комментариев.
Мы используем его довольно успешно, и я рекомендую программистам пользовательского интерфейса разбивать css и javascript файлы на более мелкие и логически именованные файлы и оставлять в них довольно много комментариев для документации. Конечный пользователь всегда в конечном итоге получит один css и js, который имеет разное имя для каждой сборки.