Как обычно, ближе к релизу студии начинают выкладывать внятную документацию.

Про что собственно речь: новый формат файлов проектов + кросплатформенное API к нему.
Точнее, не так: новое API рослина для поддержки нового формата проектов, кросплатформенность и интеграция через OmniSharp уже бонусом

Для начала для .net core и кросплатформенных библиотек, остальное позже подтянется.
Почему оно нужно — кто работал с .Core в студии и так знает, остальным рекомендую список вот, мы починили key improved experiences в анонсе сабжа.

Чтоб не размазывать:
новый xproj выглядит так

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
  <PropertyGroup>
    <Version>1.2.3-beta</Version>
    <Authors>Test Authors</Authors>
    <Product>Test Product</Product>
    <AssemblyTitle>Test AssemblyTitle</AssemblyTitle>
    <Copyright>Copyright (c) Test Authors</Copyright>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="../TestLibrary/TestLibrary.csproj" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App">
      <Version>1.0.1</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.NET.Sdk">
      <Version>0.0</Version>
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

(угу, поддержка SemVer и интеграция с нюгетом из коробки), для эстетов возможно редактирование проекта без выгрузки из студии. Человекочитабельный (и человекописабельный) формат пока не планируется и как по мне — нафиг не нужен. Предложения есть, кому надо — подключайтесь.

Ссылки:
* Оф. анонс
* Репо (жаловаться сюда же, в issues) и cli tools для работы с проектами
* Документация к VS CPS

Здравствуйте, Sinix, Вы писали:


S>(угу, поддержка SemVer и интеграция с нюгетом из коробки), для эстетов возможно редактирование проекта без выгрузки из студии. Человекочитабельный (и человекописабельный) формат пока не планируется и как по мне — нафиг не нужен.

Что-то я не понял. А вышеприведенный XML — это не оно? Вполне читабельно и редактабельно, вроде. Или это про другое?

Здравствуйте, fmiracle, Вы писали:

S>>(угу, поддержка SemVer и интеграция с нюгетом из коробки), для эстетов возможно редактирование проекта без выгрузки из студии. Человекочитабельный (и человекописабельный) формат пока не планируется и как по мне — нафиг не нужен.
F>Что-то я не понял. А вышеприведенный XML — это не оно? Вполне читабельно и редактабельно, вроде. Или это про другое?

Ну так это нам ехать, а народ шашечки требует. Типа POCO-support (msbuild ticket) и чтоб оно сохранялось в любой формат, от json и до xaml или нового диалекта поверх XML (пример из комментариев к анонсу взят).
Подвох в том, что помимо сериализации нужно ещё автодополнение (весьма продвинутое, с подстановкой пакетов из нюгета), проверка схемы, поддержка произвольных pre- & post- build actions, сохранение совместимости с существующим инструментарием поверх msbuild, подхват изменений наживую и тыды и тыпы.

В общем, пожелание из серии "а сделайте мне студию x64, там делов-то — ключик при сборке поменять".

Здравствуйте, Sinix, Вы писали:

нужно не забывать что нет коре делает три разных команды. херово делают. и непонятно.

Здравствуйте, VladCore, Вы писали:

VC>нужно не забывать что нет коре делает три разных команды. херово делают. и непонятно.

В смысле?
Там те же люди, что и в команде старого фреймворка.

"Непонятно" — прямое следствие политики "дать товарищам поэксперементировать". Эксперимент удался, про совместимость с готовой codebase вспомнили где-то за полгода до релиза.

Здравствуйте, Sinix, Вы писали:

S>Про что собственно речь: новый формат файлов проектов + кросплатформенное API к нему.
S>Точнее, не так: новое API рослина для поддержки нового формата проектов, кросплатформенность и интеграция через OmniSharp уже бонусом
S>...
S>Чтоб не размазывать:
S>новый xproj выглядит так

Я что-то может не понял? С виду обычный мсбилд-проект. Ну, может прикрутили еще одну поддержку нюгета. Что тут революционно нового?

Здравствуйте, VladD2, Вы писали:

VD>Я что-то может не понял? С виду обычный мсбилд-проект. Ну, может прикрутили еще одну поддержку нюгета. Что тут революционно нового?
Я ждал этого комментария

Ничего принципиально не поменялось, но в комментах к анонсу "новый" формат воспринимают без возражений, все пожелания — чтоб покороче и "json всё-таки лучше был".

Юмор ситуации в том, что во всех предыдущих холиварах, особенно в майских, когда только объявили об отказе от xproj, народ не менее массово плевался от msbuild, считал байты в разных форматах, заявлял, что msbuild непригоден для использования, что ms сливает дотнет и что xml никогда не будет удобнее json-а. В общем как обычно, 90% обсуждающих (особенно самые активные) не имеют никакого представления о сабже.

Здравствуйте, Sinix, Вы писали:

S>Я ждал этого комментария

Я рад, что не подвел!

S>Юмор ситуации в том, что во всех предыдущих холиварах, особенно в майских, когда только объявили об отказе от xproj, народ не менее массово плевался от msbuild, считал байты в разных форматах, заявлял, что msbuild непригоден для использования, что ms сливает дотнет и что xml никогда не будет удобнее json-а. В общем как обычно, 90% обсуждающих (особенно самые активные) не имеют никакого представления о сабже.

Тут оно как? Может json и по читабельнее ХМЛ-я. Но:
1. Нет ничего хуже чем менять коней на переправе. Смена форматов — это гимор для пользователей.
2. Для мсбилда наделана куча расширений. Их все в топку?
3. Все же файлы проектов вручную правятся не так часто. Хотя это не мой случай. Только сегодня часа 3 их правил .
4. Если в обычном дотнете останется МСБилд, а в Коре будет самостийный формат, то это будет форменным издевательством, так как придется поддерживать оба формата.

Здравствуйте, VladD2, Вы писали:

VD>Тут оно как? Может json и по читабельнее ХМЛ-я. Но:

Вот не поверишь, буквально те же аргументы года два назад были, но их откладывали с комментарием в стиле "you will eventually be able to reference an XPROJ (project.json) from a CSPROJ file", ну т.е. всё будет, как только — так сразу. Самый популярный вопрос — как использовать старые проекты, вот первый попавшийся, но я ещё штук пять точно помню. Ответ какобычна — "а пока просто создайте рядом xproj". Хипстеры, сэр


UPD Забавно, пролистал старый топик и походу я там накаркал

Автор: Sinix
Дата: 12.05.16

:

Для сложных проектов, с reusable parts, таргетингом, conditional references, conditional includes, pre&post-build actions и прочими радостями энтерпрайза городить что-то на json — как с перочинным ножиком на медведя. Несерёзно от слова совсем.

В общем, все пункты есть в issues новой project system или запрошены в комментариях к анонсу. Упс

Здравствуйте, Sinix, Вы писали:

S>Вот не поверишь, буквально те же аргументы года два назад были, но их откладывали с комментарием в стиле "you will eventually be able to reference an XPROJ (project.json) from a CSPROJ file", ну т.е. всё будет, как только — так сразу. Самый популярный вопрос — как использовать старые проекты, вот первый попавшийся, но я ещё штук пять точно помню. Ответ какобычна — "а пока просто создайте рядом xproj". Хипстеры, сэр

Ну, видимо пришло время ПМ-ов. Они посмотрели на криативное творчество и поняли, что надо добавить немного сурового протекционизма.

Кстати, было довольно не сложно сделать для МСБилда поддержку джейсона. Транслятор мог бы быть очень простым. И там, и там дерево. А вот зачем еще один новый формат клепать? В прочем, ясно зачем — его писали не они .

ЗЫ

Вспоминаю времена когда Явщики начали разрабатывать разные билд-системы вроде Ant-а. Я тогда тоже спрашивал — "А чем хуже Make?". Мне отвечали — а как же? Make же не использует ХМЛ и в нем нужно использовать платформно-зависимые утилиты!

Прошло около 15 лет и оказывается, что ХМЛ — это плохо, а утилиты написанные для МСБилда ни фига не переносятся на другие версии дотнета.

Боюсь скорое создатели PowerShell скоро создадут PowerMake и история повторится на новом ветке.

Здравствуйте, VladD2, Вы писали:

VD>Боюсь скорое создатели PowerShell скоро создадут PowerMake и история повторится на новом ветке.
Тут такое дело…

UPD И с авторами почти угадал — Technical Evangelist for JetBrains.

Здравствуйте, Sinix, Вы писали:

VD>>Боюсь скорое создатели PowerShell скоро создадут PowerMake и история повторится на новом ветке.
S>Тут такое дело…

Гы-гы. Но у этого замечательного средства авторы не кошерные. Теперь в МС должны найти фатальный недостаток (тм) в этом проекте и создать свой.

Здравствуйте, Sinix, Вы писали:

S>Хипстеры, сэр:))

Нет, хипстеры — это YAML.

Насчёт human writable формата — я только за. Например, конфигурация VSCode посредством джейсона вместо полотен из галочек и комбобоксов — шаг вперёд. Но вводить всё-таки нужно поэтапно. Тут и так каша в голове от всех этих netcore, netstandard, dnvm, dnx, dotnet, etc. Пусть бы оно сначала утряслось, а потом выкатывайте новую проектную систему с поддержкой миграции со старой. XML можно и затерпеть, не настолько он плох — если упростят его непосредственное редактирование.

Q>Насчёт human writable формата — я только за. Например, конфигурация VSCode посредством джейсона вместо полотен из галочек и комбобоксов — шаг вперёд.
json даже с автокомплитом — ни разу не human writeable. Придётся за каждым тэгом лазить в SO, запоминать наизусть магические значения тэгов, да ещё вникать куда конкретно среди веток настроек этот тэг пихать.

Корень проблем тут в том что галочки и комбобоксы захардкожены в студию, и если в студии подходящей галочки нет приходится идти править проект ручками. Итого получаем недо-UI и квесто-XML. Если бы они додумались до того что полотно настроек можно генерировать по проекту, всем его референасам, build.targets и установленным студийным аддонам + сделали полнотекстовый поиск в этом окне настроек (как сделали поиск в окне Tools->Options), не было бы нужды вообще знать какой там формат.

Здравствуйте, hi_octane, Вы писали:

_>json даже с автокомплитом — ни разу не human writeable. Придётся за каждым тэгом лазить в SO, запоминать наизусть магические значения тэгов, да ещё вникать куда конкретно среди веток настроек этот тэг пихать.

Лазить за тегом гораздо проще, чем за GUI-настройками. И отвечать на вопросы на SO проще, если ты просто приводишь в проимер тег, а не пути доступа к настройке в GUI. С проблемой discoverability сложнее; в VSCode просто приводят в пример базовый шаблон.

Здравствуйте, Sinix, Вы писали:

S>Ничего принципиально не поменялось, но в комментах к анонсу "новый" формат воспринимают без возражений, все пожелания — чтоб покороче и "json всё-таки лучше был".

Ну не знаю. Поигрался тут с проектом в JSON — по мне так нет какой-то принципиальной разницы, что с ним, что с xml.
От руки все равно не напишешь, т.к. голова опухнет все ключевые слова помнить, а подредактировать автоматически сгенерированную болванку — большой разницы нет в чем. JSON чуть короче, но зато в нем комментариев нет

Проект еще ладно, а вот appsettings.json в плане отсутствия комментариев напрягает.

Q>Лазить за тегом гораздо проще, чем за GUI-настройками. И отвечать на вопросы на SO проще, если ты просто приводишь в проимер тег, а не пути доступа к настройке в GUI. С проблемой discoverability сложнее; в VSCode просто приводят в пример базовый шаблон.

Вот если принять за хреновое окошко настроек студийный Solution Explorer, как проще и быстрее найти один конкретный файл — вбив кусок его имени в окошке Search, или порывшись *.csproj? Неужели тебе вторым способом проще?

Здравствуйте, hi_octane, Вы писали:

_>Вот если принять за хреновое окошко настроек студийный Solution Explorer

Почему ты принимаешь за хреновое окошко настроек именно Solution Explorer, а не... хм... хреновое окошко настроек?

Здравствуйте, VladD2, Вы писали:

VD>Я что-то может не понял? С виду обычный мсбилд-проект. Ну, может прикрутили еще одну поддержку нюгета. Что тут революционно нового?
Революционного, вроде как ничего. Но, если я всё правильно понял, получилось неплохое эволюционное развитие:

• Проектную систему отвзяли от VisualStudio. Теперь она разбита на CPS Core (общее ядро, никак не связанное с VS) и CPS VS (которая интегрирует Core в VS). На сколько это существенно, сказать не могу. Вроде
  
• Все многообразие проектных систем (все VSLangProj-VSLangProj140, а также, судя по всему, VCProject) свели к общему знаменателю
  
• Убрали привязку к COM. Все расширения на основе MEF
  
• Четко обозначили точки расширения (для модификации существующих или создания собственных типов проектов): создание собственных элементов дерева проектов, свойства проекта, запуск отладчика, деплой, ...

По большому счету, эти изменения важны для разработчиков различных расширений (таких, которые требуют собственных типов проектов) для VS. Ну и изменения эти примерно как переход в VS 2010 от Language Services к Editor Extensions.
Теоретически, сейчас дорабатывать проектную систему должно стать серьезно проще и быть может, как в случае с Roslyn (после зоопарка компиляторов и языковых сервисов), развитие проектных систем может ускориться.

Здравствуйте, Sinix, Вы писали:

S>Точнее, не так: новое API рослина для поддержки нового формата проектов, кросплатформенность и интеграция через OmniSharp уже бонусом

Немного дополню (т.к. сам эту фразу понял изначально несколько иначе):
В репозитории roslyn-project-system лежит проектная система для Visual Basic и C#, сделанная на базе CPS. Самого CPS там нет (и, судя по всему, пока его в исходных кода не достать — есть только пакет с референсами).

Кстати, несколько (как мне кажется) интересных моментов по поводу этого репозитория:

• Объем кода, который требуется для реализации своего типа проектов всё же достаточно серьезен. (Я как-то надеялся, что теперь всё будет делаться "само собой"
  
• В репозитории лежит пара интересных проектов: Microsoft.VisualStudio.AppDesigner и Microsoft.VisualStudio.Editors. Судя по всему, это всевозможные редакторы настроек проектов для C# и VB: собственно настройки, редактор ресурсов, application designer, ... — которые "выдернули" непосредственно из VS. И да, написаны они на VB.

Q>Почему ты принимаешь за хреновое окошко настроек именно Solution Explorer, а не... хм... хреновое окошко настроек?
Это самый простой пример который показывает что GUI из дерева и поиска для решения задачи выбора нужного тэга (в данном случае файла) таки удобнее чем ползание с текстовым редактором по форматам сериализации. Но из-за косности мышления тех кто пилит окна настроек студии у нас есть странный комплекс из убогого окошка, в которое все настройки во всех сочетаниях ручками впилить никаких бюджетов не хватит + XML-я. Замена XML-я на json не решает проблемы

Здравствуйте, hi_octane, Вы писали:

_>GUI из дерева и поиска для решения задачи выбора нужного тэга (в данном случае файла) таки удобнее чем ползание с текстовым редактором по форматам сериализации.

В VSCode древовидное отображение файлов не мешает text-based настройкам.

Здравствуйте, Михаил Романов, Вы писали:

МР>* Проектную систему отвзяли от VisualStudio. Теперь она разбита на CPS Core (общее ядро, никак не связанное с VS) и CPS VS (которая интегрирует Core в VS). На сколько это существенно, сказать не могу. Вроде

С CPS вопросов нет. Но это поддержка проектов для IDE. И она на безе все того же МСБилда сделана.

МР>* Все многообразие проектных систем (все VSLangProj-VSLangProj140, а также, судя по всему, VCProject) свели к общему знаменателю
МР>* Убрали привязку к COM. Все расширения на основе MEF
МР>* Четко обозначили точки расширения (для модификации существующих или создания собственных типов проектов): создание собственных элементов дерева проектов, свойства проекта, запуск отладчика, деплой, ...

Это все тоже к CPS относится. Формат проекта тут не причем. По сути тупо дали железной линейкам по пальцам всем кто игрался с разными новыми форматами и приказали вернуться к МСБилду. А в пиаре подали это как новаторство.

МР>По большому счету, эти изменения важны для разработчиков различных расширений (таких, которые требуют собственных типов проектов) для VS. Ну и изменения эти примерно как переход в VS 2010 от Language Services к Editor Extensions.

Это и есть часть этого перехода. До появления CPS расширения можно было делать только на уровне редактора кода. А теперь и на уровне проектной системы. По усти просто заменили MPF на CPS. И произошло это за долго до выхода 15-й студии. Уже в 2015-й шарпоуский С++-ный проекты на CPS (если не ошибаюсь) сделаны.

МР>Теоретически, сейчас дорабатывать проектную систему должно стать серьезно проще и быть может, как в случае с Roslyn (после зоопарка компиляторов и языковых сервисов), развитие проектных систем может ускориться.

Это да. Только мало кому нужно дорабатывать проектные системы. Расширения на уровне компилятора намного более востребованы будут.

Это скорее облегчение создания своих проектных систем для других языков, отказ от КОМ-а, ну и общая кодовая база для проектных систем в МС. Все это конечно здорово. Но это именно про CPS и Студию, а не про формат файла проекта в Дотнет Кор.

Q>В VSCode древовидное отображение файлов не мешает text-based настройкам.
Ты наверное сразу в 10 ветках отвечаешь. Hint: я никогда не утверждал что в VSCode что-то чему-то мешает