Как Bower, Grunt и Yeoman вписываются в рабочий процесс Visual Studio.NET?

Ответ 1

Существует расширение Package Intellisense для Visual Studio, которое добавляет поддержку пакета bower и npm

Расширение Grunt/Gulp launcher для запуска задач grunt/Gulp

Прочтите эту замечательную статью, написанную Скоттом Хансельманом для получения дополнительной информации:

http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx

UPDATE:

Эти функции теперь полностью интегрированы в Visual Studio 2015: http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015

Отличные советы от john papa: http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/

Ответ 2

Согласно сообщению блога Скотта Хансельмана, он говорит об этой причине, почему VS-разработчик может захотеть поддерживать эти инструменты:

Некоторые из вас могут спросить, почему бы не использовать NuGet для JavaScript? Почему бы не расширить MSBuild для создания CSS/JS? Просто. Потому что там уже богатый экосистемы для такого рода вещей. NuGet отлично подходит для серверной части библиотеки (и некоторые клиенты), но есть так много CSS и JS libs на npm и bower. MSBuild отлично подходит для серверных сборок, но может быть чрезмерным при создании клиентского приложения.

Итак, используйте оба. Это инструменты в вашем наборе инструментов. Добавление поддержки для Gulp, Grunt, Bower, npm (и другие вещи, в будущем, если необходимо) означает более привычную среду для интерфейсных разработчиков, выполняющих ASP.NET и он открывает двери для разработчиков ASP.NET для ввода JS и CSS сообщества библиотек каждый день.

Хотя я все равно буду заинтересован в том, чтобы другие люди рассматривали, как эти инструменты вписываются в "рабочий процесс" разработчика VS. Например, "Прежде чем я установил Grunt, я не смог легко... blah".

Обновление

Я буду хранить некоторые обновления здесь, когда я узнаю что-то.

• Итак, новое учение №1: внешний вид эхо-леса, клиентский код. В то время как VS подделывает серверные элементы и шаблоны проектов (которые не меняются в течение месяцев/лет), Йомен может помочь, например, с шаблоном для быстро изменяющихся фреймворков JS MV *.

• Новое обучение № 2: инструментарий не готов для бизнес-разработчиков Enterprise.

Первая проблема заключается в том, что npm загружает зависимые пакеты во вложенные подпапки и исчерпывает эту модель, поэтому вы заканчиваете путь к папкам длиной 100 символов. Windows и некоторые инструменты сходят с ума. Есть обходные пути, но это серьезный недостаток.

Последний Node и некоторые дополнительные параметры командной строки теперь делают это лучше.

Разработчики, работающие под управлением Windows, часто находятся в корпоративных настройках, что означает прокси-фильтры и auth. Для меня мне нужно было установить локальный прокси-сервер Cntlm, чтобы заставить NPM и другие инструменты работать через наш прокси-сервер, что нарушает нашу ИТ-политику, я просто не сказал им.

Некоторые пакеты NPM, похоже, хотят клонировать репозитории Git с помощью SSH! Порт 22 не открыт; потому что сообщество настолько ориентировано на Linux/Mac, что такие проблемы возникают из-за того, что они не являются проблемой для многих разработчиков творческих агентств, а затем могут длиться несколько месяцев.

• Новое обучение №3: как динамически загруженные JS файлы заканчиваются как содержимое в файле проекта и, таким образом, добавлены в пакет MS Deploy, все еще неизвестны.

Обновление для обучения 3, мы создали сборку, которая только что изменила конфигурационные файлы, затем мы использовали командную строку MSDeploy для копирования файлов по отдельности на целевой сервер. Не то, что я сделал бы, если бы я работал один, потребовалось несколько недель, чтобы автоматизировать все это.

Ответ 3

С обновлением Bower быстрее. Каждый раз, когда выпускается новая версия или обновление, мы можем легко найти ее в Bower. Вам больше не нужно ждать, так как мы должны были с NuGet.

Итак, мы можем сказать, что NuGet по-прежнему является королем на стороне сервера, но Bower - новый король клиентской земли.

Взгляните на это сообщение для получения более подробной информации и посмотрите простой пример: http://nearsoft.com/blog/bower-and-asp-net-5-a-tutorial/

Ответ 4

Чтобы ответить на исходный вопрос с точки зрения как корпоративного, так и случайного развития...

История

Visual Studio всегда была стандартным инструментом разработки для эффективного создания крупномасштабных корпоративных приложений для настольных компьютеров, мобильных устройств и Интернета. Это включало как клиентские, так и серверные веб-приложения, созданные с использованием форм, MVC и .NET Framework. Конечно, то, что делает Visual Studio настолько привлекательным, - это сила, стоящая за ней, что дает разработчикам возможность быстро генерировать или разрабатывать общие решения с помощью шаблонов проектов, что позволяет разработчикам сосредоточиться на решении бизнес-задач.

Для простых веб-сайтов на стороне клиента, которые используют несколько библиотек и требуют минимального взаимодействия с данными, такой инструмент, как WebMatrix, часто бывает достаточным из-за того, что он легковесен и способен легко обслуживать веб-сайты.

Многие из этих инструментов и технологий можно найти в Microsoft/web.

Расхождение

В то же время существовало процветающее сообщество с открытым исходным кодом, которое разрабатывает многие из библиотек и фреймворков, которые стали популярными для создания современных веб-сайтов и веб-приложений.

Для разработчиков, работающих с технологией Microsoft Stack, разрыв был первоначально перекрыт путем интеграции NuGet в Visual Studio. Многие, но не все, библиотеки и фреймворки были доступны как пакеты NuGet; и для работы с этими технологиями было много поддержки от Microsoft. Microsoft также создала собственную мини-экосистему с открытым исходным кодом под названием CodePlex для поддержки разработки и совместного использования проектов, обычно ориентированных на их технологию в некоторых путь.

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

Такие рабочие процессы включают в себя:

• управление пакетами на стороне клиента через Bower из Twitter (Bootstrap и т.д.)
• node управление пакетами через NPM
• с помощью Yeoman (например, генераторы для ASP.NET и нокаут)
• автоматическая задача, выполняемая через Gulp и Grunt
  • предварительная компиляция CSS из SASS или LESS
  • транслировать языки, такие как ES6 или TypeScript
• тестирование (Jasmine, Karma и т.д.)
• комплектация и развертывание (Webpack и т.д.)

К сожалению, большая часть этого процесса - ручной процесс, такой как определение правильного пакета для задания или создание различных задач, которые могут быть автоматически запущены. Каждый из них поистине является предметом сам по себе! Это не редкость - просто найти пакет или команду для чего-то, что в конце концов могло бы - и разработчики Visual Studio сказали бы - автоматизированы.

Convergence

Microsoft медленно продвигается не только от поддержки разработки с открытым исходным кодом, но и для ее охвата. Он сделал многие из своих основных технологий доступными для сообщества с открытым исходным кодом через GitHub, а также собственный .NET Foundation.

Основная попытка слияния Microsoft заключалась в том, чтобы представить код Visual Studio для нескольких платформ - предлагая упрощенный опыт разработки, который подходит для рабочего процесса который стал популярным среди сообщества с открытым исходным кодом.

Тем не менее, Visual Studio Code можно рассматривать как важный шаг назад для разработчиков, используемых для большей части мощности и простоты, предлагаемых через Visual Studio благодаря автоматизации задач и шаблонов проектов. Microsoft представила Web Essentials для 2010 и 2013 изданий для поддерживать; но, как многие наблюдали, это было просто больше усилий, чтобы продемонстрировать поддержку, а не полную интеграцию в рабочий процесс разработчика.

За кулисами Microsoft надеялась разместить .NET Framework на других платформах и установить .NET Core. Начиная с Visual Studio 2015 - в частности Update 3 и Node Инструменты - существует гораздо более глубокая поддержка рабочего процесса разработки с открытым исходным кодом с интеграцией NPM и Bower, а также задачи. Они по-прежнему требуют ручного вмешательства, но наравне с рабочим процессом вне Visual Studio. Он по-прежнему чувствует себя чуждым, но он туда попадает.

Будущее

Со всем, что Microsoft инвестировала, ясно, что следующим шагом будет объединение многих шагов, предпринятых для внедрения разработки с открытым исходным кодом, путем предоставления более визуального и автоматизированного опыта разработчикам Visual Studio. Это будет включать шаблоны, которые генерируют богатые веб-приложения, которые не только определяют все необходимые пакеты и зависимости, но и возможность связывания для распространения.

Тем временем, я думаю, что это отличное время для разработчиков Visual Studio, чтобы почувствовать текущий рабочий процесс, если просто оценить, как это делают другие ребята. Это будет незадолго до того, как большая часть этого будет просто нажата.