Зміни Project.json

минулого тижня ми анонсували розклад виходу 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 проектів.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.