Главная

Изменения Project.json

2016-05-24 в 11:38, admin, рубрики: .net, .net core, .net standard, ASP, ASP.NET, asp.net core, C#

На прошлой неделе мы анонсировали расписание выхода RC2/ RTM версий .NET Core и ASP.NET. Сейчас, когда мы уже выпустили RC2, я бы хотел раскрыть чуть больше подробностей о переходе .NET Core с проектов типа .xproj/project.json на .csproj/MSBuild.

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, сообществом и даже этим блогом. Двигаясь вперед, мы будем стараться и объявим сначала через этот блог основные изменения по мере того, как мы будем готовы предоставить больше контекста о том, что меняется и почему.