Я пытаюсь создать веб-приложение VS2015 ASP.NET v5 на нашем сервере сборки (в основном, за пределами Visual Studio). Наши существующие сценарии просто вызывают msbuild с файлом csproj, но с этим проектом я получаю:
Файл проекта пуст
Какова «история» «создания» этих новых веб-приложений вне Visual Studio? Я считаю, что они все еще могут ориентироваться на .NET 4.5 (я надеюсь на это, поскольку мы не будем обновлять веб-серверы в ближайшее время), поэтому предполагал, что это возможно.
Ну нет .csproj в проекте dnx все что нужно dnu для сборки проекта содержится в project.json. Есть файл xproj, но вы можете его игнорировать. Microsoft, наконец, решила увидеть свет и использует xproj только для конкретных «вещей» VS, а детали проекта, не зависящие от IDE, помещаются в project.json.
Таким образом, для создания проекта dnx все, что вам нужно, — это правильная версия dnx и исходный код проекта. Теперь, насколько я знаю, нет готовых решений, но все делается с помощью команд командной строки, поэтому написать что-то должно быть легко. Все зависит от того, насколько надежное решение вы хотите построить.
Чтобы создать проект dnx из командной строки (при условии, что у вас установлен правильный dnx и он активен), достаточно всего двух команд. dnu restore запускает проверку зависимостей, а dnu (часть dnx) имеет встроенный клиент nuget, поэтому при необходимости он будет обращаться к зависимостям и захватывать их. dnu build запускает эту фактическую компиляцию.
Итак, перейдите в корень проекта (который содержит project.json) и запустите dnu restore, затем dnu build.
Это становится более сложным, если вам нужно динамически поддерживать разные версии dnx. Имейте в виду, что версии dnx идентифицируются по времени выполнения (coreclr или clr), архитектуре (x86, x64 и т. д.) и номеру версии. Итак, если вы нацелены только на сборку x64 на clr (полная среда выполнения .net), которая устраняет две переменные, но что произойдет, если для проекта требуется более новая версия среды выполнения, чем та, что установлена на сервере сборки? Например, вы установили (вручную с помощью dnvm) dnx-clr-win-x64.1.0.0-beta4 на сервер сборки, но в какой-то момент в будущем разработчику потребуется dnx-clr-win-x64.1.0.0- beta6-1200 для устранения ошибки.
Упрощенным решением было бы просто установить новые версии среды выполнения по мере необходимости и построить все проекты на основе самой новой из необходимых. Это не так плохо, как может показаться на первый взгляд. После того, как dnx выйдет из бета-версии, изменения в среде выполнения должны быть редкими. Помните, что среда выполнения — это код очень низкого уровня и неуправляемые библиотеки DLL. Это заглушка начальной загрузки, над которой находится BCL. Надеюсь, не должно быть так много изменений в dnx для данной ОС, архитектуры и среды выполнения.
Для более надежного решения вы можете использовать сценарии, чтобы найти версию среды выполнения, необходимую для проекта. Находится на уровне решения global.json. Затем сценарий может использовать dnvm list, чтобы определить, установлена ли у него эта среда выполнения. Если это не так, используйте dnvm install или dnvm upgrade для установки необходимой версии. Перед запуском сборки он будет использовать команду dnvm use, чтобы активировать правильную среду выполнения, а затем продолжить с dnu restore и dnu build.
Честно говоря, я ожидаю, что появятся довольно надежные решения. Исполнители задач (gulp, grunt и т. д.) являются первоклассными гражданами в .NET 5. Скорее всего, ваш рабочий процесс будет включать в себя Bower для разрешения зависимостей на стороне клиента, npm, grunt/gulp и некоторые пакеты задач для таких вещей, как минимизация файлов js. Серверу сборки понадобится все это, поэтому наличие задачи сборки в виде пакета grunt или gulp кажется вполне подходящим.
