На прошлой неделе мы анонсировали расписание выхода RC2/ RTM версий .NET Core и ASP.NET. Сейчас, когда мы уже выпустили RC2, я бы хотел раскрыть чуть больше подробностей о переходе .NET Core с проектов типа .xproj/project.json на .csproj/MSBuild.
Когда команда ASP.NET начала работу над ASP.NET 5 (ASP.NET Core уже), то одной из главных целей была возможность легкого создания и разработки приложений на Windows, Mac и Linux. Это повлекло за собой создание систем проектов .xproj/project.json. Ключевыми фичами были:
Продолжая разработку, мы расширяли роль самого .NET Core:
Как это влияет на project.json? Одним из ключевых принципов .NET как платформы — возможность совместного использования кода нашими разработчиками во всех моделях приложений .NET (WinForms, WPF, UWP, ASP.NET, IOS, Android и т.д.). Это создает ряд проблем: хоть project.json отлично подходит для создания веб-приложений и библиотек классов, но в то же время не позволяет унификацию с другими моделями приложений.
У нас было два пути. Первым был перенос всех .NET проектов на использование project.json. Это потребовало бы от нас создания/изменение инструментария, который бы затрагивал все типы проектов в Visual Studio, Xamarin и наших партнеров, таких как Unity. Мы должны были бы расширить project.json для поддержки всех видов сборки, требуемых каждым из этих типов проектов, а также предоставления истории миграции. Другим путем могло стать создание моста между .xproj и .csproj проектами так, чтобы последний мог бы ссылаться на проект .xproj в Visual Studio и Xamarin Studio. Данный подход имеет свои недостатки, например, когда клиент создает проект, то он теперь должен выбирать между .xproj и .csproj, что только добавляет больше возможностей выбора и сложности.
Рассмотрев варианты выше, стало очевидно, что было бы легче перенести .NET Core проекты на .csproj/MSBuild, что позволило бы всем .NET проектам использовать один и тот же набор инструментов и систему сборки.
В то же время, мы не планируем отказываться от преимуществ project.json. Так, мы планируем расширить .csproj для поддержки недостающей функциональности:
Т.к. весь .NET будет использовать один и тот же набор инструментов, то можно заняться затем и улучшением MSBuild. Мы будем запрашивать обратную связь от клиентов и сообщества по поводу поддержки JSON вместо XML, уменьшения количества генерируемых нашими инструментами чрезмерно подробных файлов и т.п. При условии использования одного стека, данные усовершенствования будут работать для всех .NET проектов.
Первой волной станут изменения в Visual Studio «15» RTM: при открытии любого .NET Core проекта Visual Studio автоматически сконвертирует .xproj в .csproj, перенеся данные из project.json в файлы конфигурации и сам .csproj файл. Также мы предоставим инструмент для конвертации приложений, используя консольные .NET утилиты.
Следующая волна будет после запуска Visual Studio «15», направленная на дальнейшее совершенствование опыта сборки проектов и работы с ними.
.NET Core и ASP.NET Core являются первыми .NET проектами, которые мы разрабатывали полностью открытыми. Скорее всего, вы не увидите все изменения, так как команда экспериментирует, чтобы сделать лучший продукт. Мы пытаемся найти правильный баланс прозрачности между GitHub, сообществом и даже этим блогом. Двигаясь вперед, мы будем стараться и объявим сначала через этот блог основные изменения по мере того, как мы будем готовы предоставить больше контекста о том, что меняется и почему.
На следующей неделе мы напишем о .NET Standard: как мы планируем сделать более легким совместное использование кода для всех типов .NET проектов.
MSBuild
Когда команда ASP.NET начала работу над ASP.NET 5 (ASP.NET Core уже), то одной из главных целей была возможность легкого создания и разработки приложений на Windows, Mac и Linux. Это повлекло за собой создание систем проектов .xproj/project.json. Ключевыми фичами были:
- Отсутствие перечисления файлов в проекте
- Легкость редактирования файла проекта без IDE
- Создание Nuget –пакета, используя только проект
- Кросс-компиляция для разных версий фреймворка
- Легкость переключения ссылок/зависимостей
Продолжая разработку, мы расширяли роль самого .NET Core:
- .NET Core стал платформой для Universal Windows Applications (UWP)
- .NET Core стал кросс-платформенным набором инструментов для создания как консольных приложений, так и библиотек
- Microsoft приобрела Xamarin, чтобы .NET разработчики могли создавать iOS и Android приложения (прим. переводчика: речь идет о бесплатности Xamarin tools)
Как это влияет на project.json? Одним из ключевых принципов .NET как платформы — возможность совместного использования кода нашими разработчиками во всех моделях приложений .NET (WinForms, WPF, UWP, ASP.NET, IOS, Android и т.д.). Это создает ряд проблем: хоть project.json отлично подходит для создания веб-приложений и библиотек классов, но в то же время не позволяет унификацию с другими моделями приложений.
У нас было два пути. Первым был перенос всех .NET проектов на использование project.json. Это потребовало бы от нас создания/изменение инструментария, который бы затрагивал все типы проектов в Visual Studio, Xamarin и наших партнеров, таких как Unity. Мы должны были бы расширить project.json для поддержки всех видов сборки, требуемых каждым из этих типов проектов, а также предоставления истории миграции. Другим путем могло стать создание моста между .xproj и .csproj проектами так, чтобы последний мог бы ссылаться на проект .xproj в Visual Studio и Xamarin Studio. Данный подход имеет свои недостатки, например, когда клиент создает проект, то он теперь должен выбирать между .xproj и .csproj, что только добавляет больше возможностей выбора и сложности.
Рассмотрев варианты выше, стало очевидно, что было бы легче перенести .NET Core проекты на .csproj/MSBuild, что позволило бы всем .NET проектам использовать один и тот же набор инструментов и систему сборки.
В то же время, мы не планируем отказываться от преимуществ project.json. Так, мы планируем расширить .csproj для поддержки недостающей функциональности:
- Отсутствие перечисления файлов в проекте
- Использование инструмента CLI для выполнения каких-либо операций над файлом проекта, хотя в большинстве случаев вам не придется редактировать сам файл
- Создание пакета, используя только проект
- Multi-targeting
Т.к. весь .NET будет использовать один и тот же набор инструментов, то можно заняться затем и улучшением MSBuild. Мы будем запрашивать обратную связь от клиентов и сообщества по поводу поддержки JSON вместо XML, уменьшения количества генерируемых нашими инструментами чрезмерно подробных файлов и т.п. При условии использования одного стека, данные усовершенствования будут работать для всех .NET проектов.
Первой волной станут изменения в Visual Studio «15» RTM: при открытии любого .NET Core проекта Visual Studio автоматически сконвертирует .xproj в .csproj, перенеся данные из project.json в файлы конфигурации и сам .csproj файл. Также мы предоставим инструмент для конвертации приложений, используя консольные .NET утилиты.
Следующая волна будет после запуска Visual Studio «15», направленная на дальнейшее совершенствование опыта сборки проектов и работы с ними.
Developing in the Open
.NET Core и ASP.NET Core являются первыми .NET проектами, которые мы разрабатывали полностью открытыми. Скорее всего, вы не увидите все изменения, так как команда экспериментирует, чтобы сделать лучший продукт. Мы пытаемся найти правильный баланс прозрачности между GitHub, сообществом и даже этим блогом. Двигаясь вперед, мы будем стараться и объявим сначала через этот блог основные изменения по мере того, как мы будем готовы предоставить больше контекста о том, что меняется и почему.
What’s Next
На следующей неделе мы напишем о .NET Standard: как мы планируем сделать более легким совместное использование кода для всех типов .NET проектов.
Поделиться с друзьями
Razaz
А добавление новых зависимостей как сейчас будет жить? Прописал в csproj и они подтягиваются?
szKarlen
было бы просто замечательно и логично ввиду:
Razaz
Они так же пишут что все через CLI и лазить туда руками не надо будет. Это вот как-то смущает :)
pashuk
Я так понял что project.json останется, но будет использоваться только для зависимостей, как замена для файла packages.config.
Razaz
Главное что бы референсы проекта были в одном месте, а не в двух как сейчас.
dotnetdonik
В Project.json сейчас есть два уровня настройки референcов и это врядли поменяеться глобально так как это логично — упроститься для большинства случаев, что разве.
Dependency root property: зависимости для всех target платформ под которое собирается приложение.
Dependency для каждой из выбранных для компиляции платформ, под которую настроена сборка проекта и здесь может быть достаточно большое количество узлов куда надо сборки подключать специфичные, кроме тех, что уже указаны в предыдущем пункте и подключаються неявно.
Что бы упростить все они сначала начали паковать дистрибутивы в один пакет с кучей типичных референсов и выкладывать их в нугет например — Microsoft.NETCore.App, стандартизировать какой-то набор сборок и обьедняет их в Dependency под именем .NET Platform Standard + строить карту совместимости под каждую конкретную платформу(фреймворк mono, net, netcoreapp, uap).
https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Razaz
Вы не совсем поняли:) Хотелось бы избежать ситуации когда у нас есть csproj и ppackages.xml. При изменении второго — первому пофигу.
Как с project.json дела обстоят я знаю. Вопрос что и куда перенесут и как будут цепляться референсы при csproj + project.json.
pashuk
Связка .csproj+project.json работает уже прямо сейчас в 2015 студии.
Я переводил в тестовых целях один мелкий проект — все работает.
https://oren.codes/2016/02/08/project-json-all-the-things/
Razaz
Там так же MSBuild таск будет получается как для xproj. Ну это радует. Спасибо.