Стратегия для файлов JavaScript в Azure

Я работаю над стратегией хранения и развертывания файлов JavaScript в Azure (веб-роль ASP.NET). Мои требования:

  1. Чтобы использовать минифицированные версии в продакшене
  2. Используйте оригинальные версии (т.е. не минифицированные) локальные версии в среде разработки (для упрощения отладки)
  3. Простой процесс сборки / развертывания (VS2010)
  4. Простой процесс обновления (мои файлы время от времени будут меняться)

Здесь есть отличное обсуждение Visual Studio 2010: публиковать уменьшенные файлы javascript вместо исходных, однако при этом не принимаются во внимание преимущества, которые Azure может предложить или возможность работы с несколькими экземплярами.

Я рассматриваю возможность развертывания моих миниатюрных файлов JavaScript в хранилище BLOB-объектов и использования их в производственной версии. Они будут храниться в большом элементе управления кэшем максимального возраста для кэширования на стороне клиента, а в именах файлов будет храниться версия (так что я могу легко обновить). Я приветствую отзывы об этой стратегии.

Таким образом, при разработке визуализированный HTML-код будет относиться к локальному файлу сценария, то есть:

<script src="Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>

Но в производстве результат должен использовать следующее для обозначения уменьшенной версии.

<script src="http://myblob.blob.core.windows.net/Scripts/myjavascript-0.0.1.js" type="text/javascript"></script>

Мой главный вопрос, однако, заключается в том, как лучше всего добиться автоматического переключения путей в разработке и производстве. Или пользовательский обработчик будет обычным маршрутом (и если да, то как это будет работать - я не хочу, чтобы каждый экземпляр перезагружался из большого двоичного объекта при каждом запросе).


azure javascript visual-studio-2010 asp.net minify
person Mister Cook    schedule 18.07.2011    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Относительно № 1 и 2:

Я обсуждаю стратегию для этого здесь. Основная идея состоит в том, чтобы использовать вспомогательную функцию для выдачи тега скрипта. Функция может создавать ссылку на файлы отладки в режиме отладки и минифицированные файлы в противном случае (что также упрощает локальное тестирование с минифицированными файлами). Эта же функция может обрабатывать добавление версии к пути для аннулирования кеша и т. Д.

Что касается №3:

Добавьте минификацию как шаг после сборки. Я добавил это в свой csproj (это просто файл msbuild), в котором используется yui-компрессор:

<Target Name="AfterBuild" Condition="'$(Configuration)' != 'Debug'">
  <!-- remove previous minified files -->
  <Exec Command="del $(ProjectDir)Styles\*-min.css" />
  <Exec Command="del $(ProjectDir)Scripts\*-min.js" />
  <!-- Minify javascript and css, unless we're in Debug -->
  <Exec Command="java -jar $(ProjectDir)..\yuicompressor\build\yuicompressor-2.4.6.jar -o .css$:-min.css --charset utf-8 $(ProjectDir)Styles\*.css" />
  <Exec Command="java -jar $(ProjectDir)..\yuicompressor\build\yuicompressor-2.4.6.jar -o .js$:-min.js --charset utf-8 $(ProjectDir)Scripts\*.js" />
</Target>

Это создаст уменьшенные файлы *-min.js и *-min.css в ~ \ Scripts и ~ \ Styles соответственно.

Предупреждение B / c об ошибке в версии 2.4.6 компрессора yui, вышеуказанное не будет работать, если в каталоге есть только один файл .css или .js.

person Gabe Moothart    schedule 18.07.2011
comment
Я не могу заставить это работать. Он хорошо работает локально, но когда я публикую его в Azure, мини-файлы не включаются в пакет, потому что их нет в файле проекта. Что я могу сделать для этого? - person iboware; 04.04.2012

arrow_upward
2
arrow_downward

Ваш базовый план звучит неплохо. Это даже позволит вам использовать CDN с очень небольшими усилиями (вам просто нужно заменить путь к вашей учетной записи хранения на путь к CDN).

Я не думаю, что буду слишком много думать об этом. Как предложено в другом месте, контроль - это хороший способ. Просто попросите этот элемент управления найти параметр web.config, чтобы получить корневой каталог для ваших сценариев и добавить его к пути сценария (в вашей локальной версии этот параметр будет пустым). Чтобы убедиться, что вам не придется возиться с изменением конфигурации для каждого развертывания, я бы использовал config transformations, чтобы это происходило автоматически.

person knightpfhor    schedule 18.07.2011

arrow_upward
1
arrow_downward

Для динамического переключения URL-адреса ссылок сценария при запуске из Azure необходимо поместить все блоки сценария в элемент управления пользователя и использовать этот элемент управления пользователя на всех страницах. Вы не должны размещать ссылки сценария непосредственно на aspx / главных страницах, вместо этого поместите их на ascx и используйте ascx. Это помогает сохранить общие ссылки на скрипты в одном файле, и когда вам нужно внести изменения в масштабах сайта, вы просто меняете ascx. Другой подход - использовать мой httphandler, который изменяет URL-адрес скриптов с относительного на абсолютный, чтобы упростить загрузку скриптов из домена, отличного от того, из которого запущен сайт. Конечно, вы можете использовать его для добавления абсолютного URL-адреса вашего сайта Azure. http://omaralzabir.com/loading_static_content_in_asp_net_pferent_download/loading_static_content_in_asp_net_pferent_from_download/

person oazabir    schedule 18.07.2011

arrow_upward
1
arrow_downward

Вы можете ознакомиться с проектом помощников Windows Azure CDN. Он должен делать почти все, о чем вы просите. Вы можете указать в конфигурации, хотите ли вы, чтобы ваши миниатюрные файлы автоматически развертывались в хранилище больших двоичных объектов или оставались в веб-ролях.

person Nathan Totten    schedule 19.07.2011