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

Про что собственно речь: новый формат файлов проектов + кросплатформенное 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.