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

What’s Next


На следующей неделе мы напишем о .NET Standard: как мы планируем сделать более легким совместное использование кода для всех типов .NET проектов.
Поделиться с друзьями
-->

Комментарии (10)


  1. Razaz
    24.05.2016 15:19

    А добавление новых зависимостей как сейчас будет жить? Прописал в csproj и они подтягиваются?


    1. szKarlen
      24.05.2016 15:36

      было бы просто замечательно и логично ввиду:

      при открытии любого .NET Core проекта Visual Studio автоматически сконвертирует .xproj в .csproj, перенеся данные из project.json в файлы конфигурации и сам .csproj файл


      1. Razaz
        24.05.2016 16:21
        +1

        Они так же пишут что все через CLI и лазить туда руками не надо будет. Это вот как-то смущает :)


    1. pashuk
      24.05.2016 19:23

      Я так понял что project.json останется, но будет использоваться только для зависимостей, как замена для файла packages.config.


      1. Razaz
        25.05.2016 10:48

        Главное что бы референсы проекта были в одном месте, а не в двух как сейчас.


        1. dotnetdonik
          25.05.2016 13:12

          В 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


          1. Razaz
            25.05.2016 13:17

            Вы не совсем поняли:) Хотелось бы избежать ситуации когда у нас есть csproj и ppackages.xml. При изменении второго — первому пофигу.
            Как с project.json дела обстоят я знаю. Вопрос что и куда перенесут и как будут цепляться референсы при csproj + project.json.


            1. pashuk
              26.05.2016 07:07
              +1

              Связка .csproj+project.json работает уже прямо сейчас в 2015 студии.
              Я переводил в тестовых целях один мелкий проект — все работает.

              https://oren.codes/2016/02/08/project-json-all-the-things/


              1. Razaz
                26.05.2016 11:21
                +1

                Там так же MSBuild таск будет получается как для xproj. Ну это радует. Спасибо.


  1. Alex_ME
    24.05.2016 18:31
    +2

    А мне так понравился project.json в ASP.NET 5…