Aspnetcore: [Обсуждение] Зависимость проекта после отказа от project.json

Созданный на 11 мая 2016  ·  338Комментарии  ·  Источник: dotnet/aspnetcore

После последнего выступления сообщества было объявлено о прекращении использования project.json .

Вот несколько проблем, которые я вижу в связи с этим, и хотел бы получить некоторые разъяснения.

  • [x] Большая часть материалов, не относящихся к NuGet, будет объединена с csproj. Что произойдет с материалами NuGet, если не будет project.json (nuget.json?)?
  • [x] Сохраним ли мы IntelliSense для управления зависимостями? По сути, это одна из лучших демонстрационных функций, которые у нас есть за project.json .
  • [x] Сохраняем ли мы формат JSON для управления зависимостями? XML ужасен для подобных вещей (см. Maven). JSON намного проще представить эти зависимости.

Можно ли дать четкий ответ на эти вопросы?

Спасибо,

Самый полезный комментарий

+1 к худшим новостям недели. Где по этому поводу шла дискуссия? Ничего не могу найти, просто одностороннее решение.

Я не вижу, чтобы сообщество поддержало это решение, и многие против (по последним подсчетам, от 85% до 15%). Как прошло обсуждение, кто принял решение, на основании какой информации?

Так мы поступаем в .NET Core? Компромиссное качество за закрытыми дверями, потому что мы хотим поддержать нераскрытый список устаревших технологий?

Во что бы то ни стало, давайте сделаем расширение VS, которое создает .csproj из project.json, который могут использовать люди, использующие эти старые технологии.

Но не отправляйте нас обратно в кошмар файлов проектов на основе XML. Когда они были введены, это была плохая идея, и мы платим налог за плохие слияния и трудную читаемость уже более десяти лет. Достаточно.

Все 338 Комментарий

В ходе выступления Дамиан упоминает, что, возможно, материал, связанный с Nuget, переместится во что-то, что заменит текущий пакет packages.config. Очевидно, что эти решения - справедливый путь в будущем, я сомневаюсь, что вы получите какие-либо конкретные ответы на этом этапе.

И я не согласен с тем, что «JSON явно проще для представления этих зависимостей». Есть плюсы и минусы. См. Это https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

Я согласен с изменением, если _ если_ перейдут на nuget.json. это единственная часть project.Json, которую, как мне казалось, нужно было редактировать в любом случае.

@darrelmiller Yaml, вероятно, даже лучшая альтернатива с точки зрения многословности. И вы обманули с разделенной запятыми строкой вместо массивов;).

@sandorfr Это так. Тем не менее, я подозреваю, что одна из причин возврата к системе проектов на основе XML связана с существующими значительными инструментами для систем проектов на основе XML в экосистеме .net. Мои комментарии не для того, чтобы попытаться определить лучший формат, а просто для того, чтобы указать, что XML по своей сути не плох.

Да, и это худшие новости на этой неделе. Это похоже на возвращение во времени ... :( Действительно, Xml неплох, но msbuild ... И базовый проект msbuild xml не будет таким гладким, как вы описали.

Тем не менее, я подозреваю, что одна из причин возврата к системе проектов на основе XML связана с существующими значительными инструментами для систем проектов на основе XML в экосистеме .net.

Я просто не понимаю, почему все вещи были дополнены суффиксом « core », чтобы указать, что это совершенно новая вещь, если намерение также состоит в том, чтобы нести багаж вперед, как msbuild.

Этот процесс был слишком болезненным более двух лет, но многие люди были в порядке, потому что все новые дополнения и улучшения приводили экосистему в соответствие с другими экосистемами, и все они были изменениями по уважительным причинам. Однако внезапно корпоративные разработчики темной материи начали давать обратную связь за закрытыми дверями, и мы видим, что многое предстоит перенести.

Существует не так много экосистем, которые имеют конфигурацию на основе XML. Фактически, все новые разработанные экосистемы охватывают другие форматы (YAML, JSON и т. Д.). Посмотрите на реакцию всех людей в социальных сетях, я не вижу много людей, которым нравится эта перемена. Однако обратная связь, полученная в частном порядке, кажется более важной для команды. Это неплохо, я понимаю причины, но это просто показывает, как решения обрабатываются в этой экосистеме.

+1 к худшим новостям недели. Где по этому поводу шла дискуссия? Ничего не могу найти, просто одностороннее решение.

Я не вижу, чтобы сообщество поддержало это решение, и многие против (по последним подсчетам, от 85% до 15%). Как прошло обсуждение, кто принял решение, на основании какой информации?

Так мы поступаем в .NET Core? Компромиссное качество за закрытыми дверями, потому что мы хотим поддержать нераскрытый список устаревших технологий?

Во что бы то ни стало, давайте сделаем расширение VS, которое создает .csproj из project.json, который могут использовать люди, использующие эти старые технологии.

Но не отправляйте нас обратно в кошмар файлов проектов на основе XML. Когда они были введены, это была плохая идея, и мы платим налог за плохие слияния и трудную читаемость уже более десяти лет. Достаточно.

Я думаю, что вы слишком пессимистичны - и я думаю, это главным образом потому, что мы все были этим удивлены. Пусть поделятся информацией о своих планах, а потом посмотрим. @DamianEdwards четко сказал, что они хотят сохранить хорошие части модели project.json.

На мой взгляд, это было бы:

  • не нужно указывать каждый CS-файл
  • возможность изменять файл без необходимости выгружать проект
  • возможность изменять зависимости nuget непосредственно в файле (с помощью IntelliSense)
  • возможность заменить пакеты nuget локальным источником через global.json

Что касается компиляции, я просто думаю, что ее можно будет скомпилировать без установки Visual Studio. Для меня не имеет значения, является ли фактическая команда «dotnet build» или «msbuild». Важно то, что должен быть способ скомпилировать все решение, которого, кстати, еще нет в "dotnet cli" (по крайней мере, насколько мне известно).

Если это возможно, меня устраивает любой синтаксис, который они используют. XML не очень хорош, но у JSON явно есть свои недостатки.

Изменить: я думаю, что это не меняет ни одной из фундаментальных (и отличных) идей .NET Core и т. Д.

ИМХО, основная проблема в том, что такие радикальные изменения непосредственно перед RTM не годятся. Если это произойдет во время бета-тестирования, то, возможно, разработчики / команды не будут так сильно удивлены. Подумайте об инвестициях, которые люди делают за последние 2 года . Подумайте о текущих продуктах / библиотеках / фреймворке в зависимости от системы project.json . Asp.Net находится в RC, а не в предварительной версии / альфа / бета-версии, такие изменения подрывают доверие разработчиков / команд :(.

ИМХО, основная проблема в том, что такие радикальные изменения непосредственно перед RTM не годятся.

Сначала я тоже так думал, но насколько я понимаю, это не приведет к каким-либо изменениям в коде вашего приложения. Это повлияет только на ваши файлы project.json / xproj / csproj, и они сказали, что изменение может быть автоматическим - так что это будет похоже на старые добрые шаги миграции проекта, которые уже выполнялись много раз, когда вы обновляли Visual Studio.

Кстати, я всегда думал, что иметь файл project.json и xproj (который содержит пространство имен по умолчанию для шаблонов Visual Studio и некоторые пути вывода, поэтому иногда вам нужно его редактировать) было странно.

Кстати, я всегда думал, что иметь файл project.json и xproj (который содержит пространство имен по умолчанию для шаблонов Visual Studio и некоторые пути вывода, поэтому иногда вам нужно его редактировать) было странно.

Может быть, это странно, но они отвечают на разные вещи. Project.json - единственный файл, необходимый для создания основного проекта .net, а xproj связан с проприетарным инструментарием, известным как Visual Studio. Это очень похоже на package.json и .idea, если вы используете webstorm для работы над проектами узлов. Просто разделение забот. Visual studio может скрыть project.json в разделе «Свойства», если им нравится, и предложить объединенный, тщательно подобранный графический интерфейс, если им нравится, не смешивая все вместе.

Я так долго использовал этот материал на Mac в VS Code, что совсем забыл о xproj. OTOH, я действительно пропустил отладку и еще кое-что из Visual Studio!

Я думаю, вы слишком пессимистичны - и я думаю, это в основном потому, что мы все были удивлены этим

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

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

Сейчас .NET Core создается, когда все думают, что JSON все решит. Я не верю, что JSON является более долгосрочным решением, чем XML, но я знаю, что легче объединить конфликты JSON, чем конфликты XML.

Я обнаружил, что это глоток свежего воздуха, не связанный с XML-мусором для файлов проекта, мне было легче читать файлы JSON, я обнаружил, что с файлами JSON легче работать за пределами Visual Studio, и я не хочу возвращаться к XML / MSBuild.

Да, это мои личные ощущения, и да, они субъективны, но, судя по комментариям в Твиттере и других местах, я не считаю, что они изолированы. Честно говоря, это решение заставляет меня полностью сомневаться в направлении .NET Core в целом, и особенно в том, как принимаются такие важные решения.

@DamianEdwards четко сказал, что они хотят сохранить хорошие части модели project.json.

С моей точки зрения, лучшая часть модели project.json заключается в том, что это не csproj, не MSBuild и не XML. Будут ли сохранены эти "хорошие" части? Очевидно нет. После того, как нас уговорили поверить в то, что они, наконец, попали в тупик, выяснилось, что все это было неверным направлением. Нам рассказали о новой системе сборки, о Gulp и project.json и о том, как все будет по-другому, а потом оказалось, что все это была фикция, и это снова дрянной старый MSBuild.

Я думаю, что форматы JSON и XML практически одинаковы с точки зрения слияния - оба имеют закрывающие теги (хотя в JSON это просто фигурная скобка), что означает, что у вас проблемы с пустыми / одним / многими сценариями. Просто замените пустой массив JSON на массив с элементами. Я бы сказал, что у JSON даже есть дополнительный недостаток в виде конечной запятой, которая меняет две строки, если вы добавляете элемент в список.

Вам придется перейти на YAML и т. Д., Если вы хотите этого избежать.

ИМО, проблема с csproj связана не с XML, а с тем, как Visual Studio обработала его и что он содержит каждый файл cs. Если это будет исправлено и инструменты не изменят случайным образом данные в файле, слияние больше не должно быть проблемой.

Однако с точки зрения удобочитаемости я также предпочитаю JSON. Мне удалось написать project.json с нуля - думаю, я больше не смогу делать это с помощью csproj (csproj требует случайного ProjectGuid и т. Д.). Так что для этого нам определенно понадобится поддержка инструментов / командной строки.

Меня больше всего беспокоит то, о чем я мало что слышал, это то, что project.json гораздо более декларативно, когда дело касается ссылок, чем файлы проекта .csproj . Красота зависимостей в файле project.json и то, почему я с нетерпением ждал переноса на него нашей кодовой базы, заключается в том, что вы просто говорите: «Мне нужна эта зависимость», и неважно, локальный ли это проект или Пакет NuGet. В нашем случае это даст нам большую гибкость и новые интересные возможности. Напротив, в настоящее время ссылка в файле .csproj является жестким относительным путем к файлу .dll на диске. Прямо сейчас добавление записи в файл packages.config в традиционном проекте ничего не дает, вам также необходимо добавить ссылку на конкретный .dll из этого пакета в файл .csproj . Это делается за вас с помощью инструментов NuGet внутри Visual Studio, но я не хочу использовать эти инструменты, когда добавление строки текста в файл project.json намного проще.

Я понимаю, что команда хочет сохранить все функции, предоставляемые файлом project.json и расширить возможности формата .csproj , но они также говорили о сохранении project.json в виде файла. чтобы указать ваши пакеты NuGet. Я не вижу, что это могло бы добавить по сравнению с текущей ситуацией с packages.config где простого добавления к нему записи недостаточно, потому что вам все равно нужно добавить ссылку на .dll в .csproj тоже. Если файл .csproj должен стать будущим, я бы предпочел, чтобы команда Core прошла весь путь и отбросила project.json или nuget.json или, как бы то ни было, в конечном итоге его назовут _entirely_ и добавят более декларативный способ добавления ссылок на формат .csproj . Я могу прекрасно жить, имея необходимость редактировать файл XML вместо файла JSON (хотя я, конечно, предпочитаю JSON), но было бы настоящим позором потерять декларативный характер project.json а мне не нужны два разные места, где мне нужно указать свои зависимости.

Пожалуйста, оставьте отзыв на https://www.surveymonkey.com/r/H6Q88PP

Чтобы быть ясным, при чтении примечаний к Standup, он упоминает, что один из вариантов - иметь параметр nuget install --save (см. Https://blogs.msdn.microsoft.com/webdev/2016/05/11/ Notes-from-the-asp-net-community-standup-may-10-2016 /). Хотя я думаю, что это хорошая идея, заменять «редактировать .json файл с помощью intellisense» на это я считаю плохой идеей. Я думаю, что оставаться в редакторе - это хорошая идея для некоторых из нас, кто не хочет переключаться на оболочку, чтобы делать все. Лично я предпочитаю иметь оба опыта. командная строка + пользовательский интерфейс для добавления зависимостей недостаточно.

Я программист, не хочу уходить из редактора.

Я считаю, что это ужасное решение. Вы, ребята, сказали, что хотите сделать .NET Core по-настоящему простым, но затем вносите это изменение. Меня не волнует, сколько помады вы нанесете на MSBuild, это все равно будет MSBuild, и посторонние взглянут на него и немедленно отключатся. Это никогда не будет простым форматом, редактируемым вручную. Возможно, были какие-то серьезные технические проблемы, но похоже, что они были связаны с попыткой превратить систему проектов в нечто большее, чем просто систему проектов. Если люди хотят делать более сложные вещи в своих сборках, они могут написать несколько скриптов или использовать для этого msbuild. project.json - это очень простая вещь, и я очень расстроен.

Моя любимая цитата по файлам MSBUILD?

Недавно мне пришлось потратить много времени на файлы csproj. Они выглядят и ведут себя как Ant / Maven. Это не в их пользу.
Ant / Maven любили, а затем возненавидели многие Java-разработчики. XML - это чрезвычайно подробный синтаксис, с которым нужно иметь дело.
Но настоящий убийца - один из замков. Да, вы можете использовать msbuild, чтобы делать что-то с ними, но синтаксис действительно разработан не для того, чтобы разработчик мог их читать / редактировать, а для IDE, чтобы сериализовать состояние в. Наличие средства запуска командной строки не означает, что формат удобен для разработчиков. Пока вы остаетесь в VS, вы ничего не заметите. Как только вы уходите, это уже не удобно. Файлы csproj - это одна вещь, которую я хотел бы, чтобы .Net пошла по пути, отличному от java в.

Источник

Я думаю, что важно проводить различие между MSBuild и тем, как Visual Studio в настоящее время использует MSBuild. Я годами вручную редактировал файлы MSBuild и использую их во всех своих проектах. Например, https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj.

Файлы csproj, создаваемые Visual Studio, довольно неприятны, но обвинять в этом MSBuild - все равно что сказать, что C # - дерьмо, потому что вы однажды видели, как генератор кода создает с ним уродливый код.

@darrelmiller Я согласен.

Давайте перенесем время на 6 месяцев вперед и посмотрим, является ли это моментом «увернуться от пули» или больше.

После звонка @shawnwildermuth в его блог я добавлю свои 2 цента:

Я не понимаю, почему это так важно. Я счастлив вернуться к csproj на основе XML, потому что:

  • Редактирование JSON вручную НЕ естественнее / проще, чем XML. На самом деле все наоборот ИМХО. Каждый глупый редактор дает мне завершение тега XML, легче обнаружить ошибку форматирования вручную и так далее. JSON не проще, если мне придется писать его вручную. Сказав это, я перехожу к пункту 2 ...
  • Почему вообще так много шума вокруг редактирования файла проекта с помощью редактора? Редактирование файла проекта - это НЕ то место, где я хочу проводить время как разработчик. Это должно быть разовым делом в начале нового проекта, но после этого не должно происходить очень часто, ИМХО. Если мне нужно отредактировать его с помощью JSON, XML, YAML, TOML или чего-то еще, что кому-то нравится в то время, это для меня совершенно не важно.
  • Единственное, чего я хотел бы избежать, - это тесной связи NuGet с ASP.NET . NuGet великолепен, мне он нравится, и я хочу, чтобы мой ASP.NET отлично с ним работал, но он НЕ требуется для запуска ASP.NET. Да, мне может потребоваться вытащить двоичные файлы из канала NuGet, чтобы получить функции MVC и т. Д., Но делаю ли я это через официальный канал NuGet, или если я извлекаю исходники, компилирую его локально и копирую, вставляю в папка должна быть гибкой, которая остается для меня доступной. Я не хочу, чтобы ASP.NET, csproj или что-либо еще было тесно связано с этими "поддерживающими" сторонними системами. Я хочу, чтобы они обеспечивали отличную интеграцию, но оставляли дверь открытой для настройки ! Поэтому я надеюсь, что пакеты NuGet не будут объявлены в файле .csproj и что nuget.json не будет тесно интегрирован в MSBuild.
    Тесная интеграция за четко определенным интерфейсом == ОТЛИЧНО.
    Тесная связь, если это стандарт для всех == ПЛОХО.
  • Наконец, я хочу сказать, что project.json имеет мало общего с .NET Core и ASP.NET Core. Core может предложить гораздо больше, чем файл project.json. Project.json не был новой функцией, это была попытка перепроектировать что-то, что уже существовало, в другом формате. Меня это не слишком заботит, потому что как разработчик я предпочитаю сосредотачиваться на новых функциях и возможностях, предоставляемых .NET Core для разработки отличного приложения в облаке, а не на утомительной конфигурации, которую мне приходится делать время от времени.

Я считаю, что вернуться к MSBuild - отличный шаг, потому что как разработчик я больше беспокоюсь о совместимости, и я думаю, что это ключ. MSBuild работает, и, честно говоря, он работает очень хорошо по большей части, и вместо того, чтобы заменять его чем-то новым, что приносит новые проблемы и вызывает проблемы совместимости, я предпочитаю, чтобы кто-то улучшил то, что уже работает, и сделал его лучше со временем. Все думают, что могут переписать материал и улучшить его, пока вы не поймете, что решили только небольшую проблемную область, которая была важна для вас в то время, а затем позже, когда вы захотите расширить, вы обнаружите, что воссоздаете ту же старую вещь, которая вы пытались заменить вначале. Лучше улучшить то, что уже работает.

Вот почему я, вероятно, предпочел бы улучшить Mono и закрыть пробелы вместо реализации новой кроссплатформенной среды выполнения, но это другое обсуждение.

Окончательные результаты опроса: 100 ответов для 9 миллионов разработчиков .NET, что составляет ± 10% с достоверностью 95%.

Вам понравился переход на project.json?
Да, это была одна из моих самых ожидаемых функций 19,19%
Да 39,39%
Нет 13,13%
Нет, брать 16,16% было ужасным направлением.

Вы довольны возвращением в MSBuild?
Да, теперь я могу подумать о его внедрении 9,09%
Да 16,16%
Нет 30.30%
Нет, это заставляет меня сомневаться в том, в каком направлении развивается .NET Core 29,29%
Плевать 15,15%

Вы верите, что MSBuild будет улучшена?
Улучшен? Это уже идеально. 1,01%
Да 63,64%
Нет 12,12%
Он принципиально сломан, как его можно улучшить? 20,20%
Плевать 3.03%

Как вы думаете, это решение было принято правильно?
Да, команда учла отзывы и сменила направление, когда у них было 20,41%.
Да 6,12%
Нет 24,49%
Нет, команда принимала необъяснимые, закрытые решения, не вовлекая сообщество 39,80%
Плевать 9,18%

Как это решение повлияет на ваше восприятие .NET Core?
Улучшает, они наконец-то приходят к здравомыслию 13.00%
Улучшает его на 11.00%
Ухудшает 42.00%
Ухудшает, заставляет усомниться во всем 18,00%
Плевать 16%

Опрос сделали 100 человек. Я даже не знал об этом до сих пор. Давайте посмотрим на это еще раз, когда у нас будут репрезентативные цифры, потому что 100 человек - в лучшем случае плохая шутка.

Фактически, как указано, 100 человек дают вам погрешность ± 10% с достоверностью 95%. Какой уровень уверенности вам потребуется, чтобы увидеть истинное отражение? Должны ли мы опросить всех 9 миллионов разработчиков?

Разве 800 голосов за UserVoice за распространение project.json на остальную часть VS также не отражают тенденцию?

И если мы собираемся сделать действительно репрезентативный образец, то, возможно, это следует сделать Microsoft. Поскольку они ни разу не просили предоставить информацию об этом решении, даже после неоднократных жалоб с разных сторон.

Их охват будет намного больше, чем у меня, когда я делаю частный опрос. Мне нужно будет обновить свой план SurveyMonkey, чтобы получить доступ к более чем 100 результатам за определенную плату, чтобы я мог провести опрос, который Microsoft следовало бы провести самостоятельно!

Что ж, если вы хотите иметь значимые цифры, тогда вы должны стремиться к справедливому представлению 9 миллионов разработчиков. Если у меня есть 100 подписчиков в Твиттере, которые подписаны на меня, потому что мы разделяем одинаковые интересы, и я прошу всех принять участие в опросе, тогда у вас будет 100 человек с очень односторонним мнением, представляющих только одну конкретную группу разработчиков.

Обоснование воскрешения MSBUILD, приведенное в презентации, заключалось в том, чтобы сделать возможной интеграцию между существующими инструментами и упростить для существующих проектов использование ядра .NET. Однако после переноса довольно большого проекта на ядро ​​.NET, если честно, система проектов была НАИМЕНЬШЕЙ из моих проблем. Так что использование этого как единственного оправдания не кажется мне большой причиной. Я также много лет работал с системой csproj, включая редактирование файлов вручную. Это всегда было больно. Система на основе project.json НАМНОГО проще и доступнее для всех (включая новичков). Я думаю, это цель. И все же сейчас мы делаем шаг назад, воскрешая MSBUILD. Лично я считаю, что это большая ошибка. Я проголосовал за то, чтобы сохранить project.json.

На самом деле у меня почти нет подписчиков в Твиттере, в основном это последователи разработчиков .NET Core, чьи стримы в Твиттере я публиковал.

И снова: наверняка правильными людьми для проведения такого опроса будет Microsoft? Почему мне остается быть единственным, кто действительно спрашивает людей, чего они хотят?

Почему MS не наплевать, что думают люди?

ТБХ Я не знал, что опрос проводился 30 минут назад, и я не знал, что вы проводите опрос в частном порядке. Я согласен ... если Microsoft заинтересована в реакции разработчиков на это изменение, им следует провести такой опрос. Но, возможно, они уже сделали свою домашнюю работу и поэтому вносят это изменение. Я не знаю, но я бы не всегда смотрел на вещи так негативно, потому что, в конце концов, эти ребята создают это для нас, поэтому я уверен, что они заинтересованы только в нас.

Если бы они сделали свою домашнюю работу, они бы знали, что 60% разработчиков были против этого шага, и, соответственно, общались бы и взаимодействовали. Они этого не сделали, что означает, что они понятия не имели о реакции, а значит, они не участвовали.

Я платный заказчик корпоративных лицензий для VS. Я ничего не видел. Я работаю в четырех компаниях, предлагающих голубые фишки, и также платю корпоративным клиентам. Они ничего не видели. Так кто же они занимаются с? Я задаю этот вопрос с прошлой ночи и не получил на него ответа.

Я смотрю на вещи негативно, потому что это крупное, последнее изменение фундаментальной части истории .NET Core, части, которая была известна нам как основа будущего, и мы (возможно, по глупости) взяли их в свои руки. словом, и построили конвейер CD / CI на основе этой технологии, которая сейчас совершенно бесполезна. Я также смотрю на это негативно, потому что в течение целого дня, когда я спрашивал подробности о принятии решения, царила полная радиомолчание.

Судя по тому, что я слышал, они бросили пользователей под автобус, чтобы помочь производителям инструментов. Если да, то могут ли они взимать плату за лицензию VS у производителей инструментов, а не у меня.

@shederman Хотя я согласен с результатами вашего опроса, его вопросы, очевидно, имеют уклон в предпочтительном направлении - оставаться в формате json, и это на самом деле не делает его хорошим опросом. Я воспринял это для развлечения и не стал бы серьезно относиться к его результатам (извините). Я действительно удивляюсь, почему у нас не может быть и того, и другого - так или иначе сделать его необязательным, потому что я не фанат msbuild или чего-то еще. Я люблю json, это мой друг.

Я согласен с вами, что это не идеальный опрос. Я создал его за 5 минут. Дело в том, зачем я это создаю?

Почему Microsoft не интересует, что думают люди?

Я ожидал только около 30 ответов, и я надеялся, что этого будет достаточно, чтобы убедить их возобновить обсуждение, открыто поделиться своими мыслями и пообщаться с нами должным образом, а не гоняться за чужим мнением.

Сейчас количество ответов составляет 138, но пока нет никаких признаков того, что Microsoft даже с учетом того, что, возможно, их решение было плохим. Просто очень расплывчатые объяснения, не подкрепленные фактами.

Все, что я хочу, - это должное участие в этом решении. Не важные решения принимаются за закрытыми дверями на основе секретной информации и отзывов. Это должно быть сделано открыто и прозрачно - слово, которое в этом процессе особенно упущено.

Ой, ребята, пошли. Microsoft владеет фреймворком и позволяет ему делать то, что он хочет. Но подумайте на мгновение, люди работают над этим с марта по апрель 2014 года, и незадолго до того, как будет выпущен месяц релиза, такие кардинальные изменения просто смешны. Это подрывает доверие разработчиков. Это напрасная трата времени людей. Нет необходимости создавать фреймворк с открытым исходным кодом, если вы не можете доверять сообществу. Немедленно сделайте его закрытым, чтобы никто не побеспокоил вас, когда вы будете делать такие изменения в темных комнатах.

Я прошу Microsoft извиниться и сочувствующих (MVP или членов сообщества), пожалуйста, будьте реалистами в этот раз.

@shederman

Если бы они сделали свою домашнюю работу, они бы знали, что 60% разработчиков были против этого шага,

Я был бы удивлен, если бы более 20% разработчиков экосистемы .net даже знали о существовании project.json. Иногда мы забываем, что живем в пузыре разработчиков, стоя на переднем крае новых технологических разработок.

Я считаю, что большая часть привлекательности project.json заключается в его простоте. Однако, если вы следили за его развитием с тех пор, как он был впервые представлен в день ASP Net Insiders 3 года назад, он начал накапливать все большую сложность, поскольку он пытается поддерживать больше вариантов использования. Боюсь, что для поддержки всей экосистемы .net большая часть излюбленной простоты будет потеряна.

Это не значит, что project.json не содержит каких-то замечательных новых функций, и я считаю, что сделать формат проекта более доступным для людей - это хорошо. Тем не менее, я думаю, что привнесение этого совершенства в MSBuild более достижимо и принесет пользу гораздо большему количеству людей, чем пытаться внедрить project.json повсюду.

Я был бы удивлен, если бы более 20% разработчиков экосистемы .net даже знали о существовании project.json.

Я готов поспорить, что менее 20% разработчиков в .net eco знают о MVC и Web Api. Более 70 человек используют WebForms, WCF, WebService. Я снова прошу Microsoft извиниться и посочувствовать, пожалуйста, будьте реалистичны

@shederman Ваш отчет о какой-либо уверенности в результатах вашего опроса, вероятно, неверен для населения .NET-разработчиков в целом, и он может даже не быть хорошей репрезентативной выборкой ... "они в значительной степени являются последователями разработчиков .NET Core чьи стримы в Твиттере я публиковал ". Ваша выборка не является случайной выборкой , что абсолютно необходимо для того, чтобы вы указали такой доверительный интервал, который вы подразумеваете для генеральной совокупности в целом. Даже если бы это была случайная выборка разработчиков .NET, вы не можете сообщить о 95% -ной уверенности в каждом ответе, потому что вы не смогли настроить одновременный вывод.

На основании вашего опроса населения в целом нельзя сделать никаких полезных статистических выводов. Однако я рад, что вы провели опрос. Вы представляете много отличных баллов. Я думаю, что результаты показывают, что многие люди либо расстроены, либо обеспокоены этим изменением. Однако, пожалуйста, не публикуйте ложные статистические выводы ... выдавая практически бессмысленные цифры и делая такие возмутительные замечания, как «они бы знали, что 60% разработчиков были против этого шага».

Тогда какой смысл что-то менять, если мы собираемся потревожить 70% + рыночной базы? Давайте останемся там, где мы, и продолжим постепенную эволюцию. Если он не сломан, не чините его, верно?

Я знаю, что project.json накопил сложность. Я на 100% согласен с этим. Было ли решение слить обратно в csproj? Я уже говорил людям, что я полностью поддерживаю Microsoft в том, что делаю все правильно, а не в спешке. Переход на csproj выглядит поспешным.

Зачем это делать после RC2? Откуда это взялось? Имеет ли какое-либо отношение к этому приобретение Xamarin? Была ли это интеграция dotnet-cli ? Был ли это крупный клиент? Кто знает...

Я мог объяснить массам, что RC1 -> RC2 был лучшим. Унифицировано с dotnet cli. Но как изменить project.json? Мне нечего сказать, чтобы это объяснить. Просто этого я не знаю. Люди сбиты с толку, и у меня нет веских аргументов в их пользу.

Зачем это делать после RC2? Откуда это взялось? Имеет ли какое-либо отношение к этому приобретение Xamarin? Была ли это интеграция dotnet-cli? Был ли это крупный клиент? Кто знает...

В этом суть мысли. Мы не знаем всей истории перехода на csproj. Теперь вместо того, чтобы расслабиться, расслабиться, посмотреть и понять, почему это происходит, все проклинают Microsoft и предполагают худшее. В этом нет никакого смысла. Эти ребята делают это для нас и только для нас. Они определенно не вносят таких изменений из-за 1 крупного клиента, потому что 1 крупный клиент ничего не стоит, если вы рискуете потерять все свое сообщество. Экосистема Microsoft .NET HUUUUUUGE, и заставить .NET Core хорошо вписаться в нее, очевидно, сложная задача, поэтому я предлагаю всем немного расслабиться и предположить, что за этими ребятами стоят умные люди, принимающие правильные решения, чтобы мы можем извлечь из этого максимальную пользу - в долгосрочной перспективе. Я ухожу отсюда, потому что все эти негативные преждевременные домыслы меня утомляют.

@darrelmiller Извините, когда я говорю 60%, я имею в виду 60% тех, кто ответил на опрос.

@GuardRex Вы абсолютно правы. Единственная организация, которая может дать нам хорошие результаты, - это рассеянный склероз, и им, похоже, наплевать.

Мой опрос был просто предназначен для оценки неопределенного уровня поддержки, а не для предоставления статистически значимой выборки. Я полагаю, что показал, что есть достаточно недовольства, чтобы вызвать это решение, но похоже, что Microsoft не согласна, что ж, если их радиомолчание является каким-либо признаком.

Возникает вопрос: что именно требуется, чтобы MS признал, что они, возможно, совершили ошибку? Что нужно сделать, чтобы заставить их возобновить обсуждение? Потому что на данный момент кажется, что ответ таков: «нам не важна ваша точка зрения, наше решение остается в силе, и мы не собираемся делиться причинами»

Я бы посоветовал всем немного расслабиться и предположить, что за этими ребятами стоят умные люди, принимающие правильные решения, чтобы мы могли извлечь из этого максимальную пользу - в долгосрочной перспективе.

Это то, что я сказал, сделайте его закрытым, потому что за этим стоят умные люди, и они всегда правы, а сообщество разработчиков открытого исходного кода глупо.

@shederman "не предоставлять статистически значимую выборку" ... это нормально, но я бы хотел, чтобы вы позволили опросу стоять на своем собственном достоинстве и удалили эту строку ...

Окончательные результаты опроса: 100 ответов для 9 миллионов разработчиков .NET, что составляет ± 10% с достоверностью 95%.

Это та часть, которая становится действительно рискованной. Возможно, 60% разработчиков .NET ненавидят или не любят это изменение; однако вы не можете показать это с этим образцом. Скажем так, да, многие разработчики серьезно обеспокоены этим изменением и тем, как оно было реализовано. Это ясно, и опрос действительно хорошо подчеркивает этот момент.

@abcplex : Открытый исходный код не означает, что вам нужно прыгать каждый раз, когда 16 человек открывают проблему на GitHub и кричат.

@MaximRouiller В Notes довольно хорошо объясняется мотивация изменений. И на самом деле, как я это читал, xproj заменяется csproj, а project.json, вероятно, будет переименован в nuget.json, а некоторые_ вещи будут перемещены из project.json.

И из комментариев, сделанных в стендапе, это было довольно недавнее решение, сообществу почти сразу сказали, что project.json никуда не денется до выхода RTM, поэтому изменения могут произойти снова.

Мне это кажется наиболее всеобъемлющим и прозрачным процессом, который мог произойти.

@darrelmiller Я должен с вами согласиться. Довольно прозрачно.

Если им нужна была обратная связь, я думаю, они ее получили. Во всяком случае, с этим не бороться. Люди говорили. Microsoft прислушалась. Посмотрим, могут ли они что-то с этим поделать или у них связаны руки.

Только время покажет нам сейчас.

Не думаю, что проблема была в их прозрачности. Они проделали огромную работу по обеспечению прозрачности. Я думаю, проблема в том, что они принимают важные критические решения, не зная, что об этом думает сообщество. Я знаю, что невозможно разработать комитетом, но, возможно, им стоило задокументировать список плюсов и минусов, который они рассмотрели, и представить его сообществу для чего-то столь же фундаментального, как это изменение. Надеюсь, они скоро опубликуют такую ​​информацию, но даже в этом случае похоже, что решение уже принято.

Это влияет на ранних последователей больше, чем на кого-либо другого.

JSON хорошо читается, но только тогда, когда он простой. </system> мой взгляд, ]} .

Наиболее разумные комментарии по этому поводу отражают мои собственные мысли относительно выгрузки / загрузки проектов и управления зависимостями, не нуждающихся в многословности, присущей XML.

Стоит ли обсуждать JSON и XML? Неважно ИМХО
(конечно, лично мне JSON нравится больше, чем XML, но это не важно)

Что мне действительно нравится в ASP.NET Core, так это то, что он довольно открыт и независим от Visual Studio и любой другой IDE. Если это все еще дано, у меня нет проблем с этим решением.

В этом выпуске ведется довольно много ядовитых дискуссий, из-за которых, как мне кажется, многие люди теряют зрение. Общий аргумент звучит так: «MSBuild - это плохо!» но недостаточно понимания того, что хорошо / плохо в обоих подходах.

Всем, кто заявляет, что это «шаг назад», имейте в виду, что, хотя он возвращается к «csproj», он не будет таким же, как файлы csproj, которые у нас были в течение многих лет. Во-первых, они четко заявили, что вы не увидите список файлов в «новом» формате csproj. Основное преимущество и основная причина, по которой большинству людей понравился формат project.json, заключается в отсутствии этого списка файлов.

Сразу есть разница. Взгляните на xproj сегодня, и вы поймете, чего ожидать от «нового» csproj. Он будет немного больше, но только потому, что у него будет несколько дополнительных свойств, взятых из project.json. Настоящая дискуссия заключается не в том, «насколько плохой MSBuild» и не должно быть, а в том, что вы хотите видеть в новом csproj и что вы хотите оставить в файле .json.

@dustinmoris, вы несправедливы, я думаю, что сообщество приветствовало большинство изменений, кроме этого. Это уводит нас назад, и они уже говорят о том, как они это сделают, не понимая, почему. Они говорят, что решение окончательное, поэтому сообществу, возможно, негде придумать лучшее предложение.

И да, мы редактируем файлы проекта напрямую, и мы мучительно это делали до project.json. Msbuild - это все о племенных знаниях, поэтому освоить их довольно сложно.

И фраза «это упростит миграцию с .net 4.5 на ядро ​​.net» кажется немного нечестной. Это точно не болевая точка ...

это будет не то же самое, что файлы csproj, которые у нас были годами.

Будет ли это XML? Да, я так и думал.

Основное преимущество и основная причина, по которой большинству людей понравился формат project.json, заключается в отсутствии этого списка файлов.

На основании какой информации вы это говорите? Я имею в виду, что отсутствие списка файлов - это большой плюс, но отнюдь не единственный для меня.

Взгляните на xproj сегодня, и вы поймете, чего ожидать от «нового» csproj.

Сегодня у меня нет xproj. Зачем мне такая вещь?

Настоящая дискуссия заключается не в том, "насколько плох MSBuild", и не должно быть.

Почему _не__ это обсуждение? Использование MSBuild было большим плюсом для моего принятия .NET Core. 20% респондентов моего (очевидно) ненаучного, эхо-камерного, предвзятого опроса согласны с тем, что он в корне сломан.

@shederman, ваш ответ - это именно та ядовитая дискуссия, о которой я говорю. Вы просто делаете общие утверждения (например, «MSBuild - это плохо!»), Но не подкрепляете их никаким конструктивным обсуждением.

Будет ли это XML? Да, я так и думал.

да. И? Если ваша проблема в том, что вам не нравится _XML_, тогда достаточно справедливо. Если вы думаете, что JSON превосходит XML, то продолжайте и наматывайте свои причины, но это не имеет ничего общего с _проектной структурой_ и всем, что связано с синтаксисом. К сожалению для вас, и XML, и JSON имеют свое место в мире, у обоих есть свои преимущества и недостатки, и никогда не будет однозначного «правильного» ответа на вопрос, что лучше. Опять же, если бы я был на вашем месте, я бы сосредоточился на том, какие различия в _проектной структуре_ будут с переездом.

На основании какой информации вы это говорите? Я имею в виду, что отсутствие списка файлов - это большой плюс, но отнюдь не единственный для меня.

Я никогда не утверждал, что это единственное преимущество, я просто сказал, что это было главным преимуществом. Посмотрите на любое обсуждение формата project.json несколько месяцев назад, и первое, о чем люди говорят, - насколько он меньше и проще. Это не потому, что JSON синтаксически чище, а сводится к удалению списка файлов проекта. Самый большой плюс, о котором упоминают люди, это то, что он хорошо сливается и хорошо сливается, потому что он не перечисляет в нем кучу ссылок на файлы.

Сегодня у меня нет xproj. Зачем мне такая вещь?

Вся эта дискуссия посвящена новому формату файлов проекта, и если вы не хотите сравнивать текущую ситуацию, ваше мнение будет неосведомленным.

Почему бы не об этом поговорить? Использование MSBuild было большим плюсом для моего принятия .NET Core. 20% респондентов моего (очевидно) ненаучного, эхо-камерного, предвзятого опроса согласны с тем, что он в корне сломан.

Поскольку вы на самом деле не обсуждаете _MSBuild_, вы обсуждаете способ, которым Visual Studio исторически обрабатывала проекты MSBuild, что, по признанию самой Microsoft, оставляет желать лучшего. MSBuild на самом деле уже поддерживает почти все необходимое, в том числе отсутствие необходимости перечислять каждый файл в проекте.

Более того, все, что вы сделали до сих пор в этом обсуждении, - это кричать и кричать, что вам не нравится XML, но я еще не видел, чтобы вы приводили какие-либо реальные аргументы за или против, помимо того, что well ", что, как я уже неоднократно заявлял, обычно сводится к количеству файлов, перечисленных в" старом "csproj. Если бы вы удосужились взглянуть на формат xproj, вы бы увидели, что он довольно мал, и Дэниел сказал во время выступления, что «новый» формат csproj будет примерно того же размера, что и текущий файл project.json - так что еще раз, что проблема? Вы делаете смелые заявления, но совершенно не подтверждаете их.

@neoKushan, вы скоро получите какую-то награду от Microsoft, защищая их без уважительной причины. Придем к выводу, что это худшее решение, принятое на задворках. Я рекомендую снова сделать asp net закрытым исходным кодом и позволить Microsoft и их сторонникам, таким как вы, решать, что тогда хотят, не спрашивая членов сообщества с открытым исходным кодом.

@abcplex Собираетесь ли вы внести свой вклад в беседу, кроме как

Пока вы ничего не сделали, кроме как пожаловались на изменение, не указав ни единой причины, в чем заключается ваша настоящая проблема.

@neoKushan: самое

@abcplex В после RTM . Все, что происходит в RTM, - это ваш xproj переименовывается в csproj - буквально ничего больше не меняется, и изменения будут вноситься поэтапно, с инструментами, переносящими ваши изменения за вас.

Согласитесь, что JSON против XML (против XAML, как некоторые люди просят об этом в Standup Blog Post) отвлекает от того, что должно быть достоинствами наличия какой-либо обратной совместимости с предыдущими инструментами.

И я бы сказал, что это в высшей степени ошибочное мышление. Нравится вам это или нет, но csproj и MSBuild следуют традиции ant, которая указывает инструментальной цепочке, как создать проект, а не определять его. Это очень разные вещи, но это наследие, кажется, дает проекту силу «определения», потому что теперь мы можем применить к нему логику и так далее. Это делает вещи невероятно сложными.

В старом мире я много раз видел, как файлы проекта ломались просто потому, что строка, которая «должна была находиться внизу», была перемещена вверх, или кто-то испортил переменную окружения, и внезапно мы втягивали неправильный файл .targets. Само представление о том, что элемент первого уровня (дочерний элемент корня) зависит от порядка в декларативном синтаксисе, полностью нарушено. Это земля MSBuild и csproj. Это наследие, которое мы возвращаем сюда. Теперь, чтобы разобраться в csproj, нужно «запустить» его, и запустить его точно так же, как это сделал бы MSBuild. Да, MSBuild имеет открытый исходный код, но на самом деле это ничего не исправляет. Он по-прежнему вводит единственную принудительную зависимость. Он по-прежнему полагается на файлы волшебных целей, которые находятся ... где-то.

Файл проекта должен обладать несколькими качествами, которые делают его независимым от формы инструментальной цепочки, которую данный магазин решает использовать:

  • Он должен быть доступен для редактирования / чтения человеком
  • Это должно позволять комментарии
  • Это должно быть декларативным
  • Он должен быть автономным
  • Он должен быть разработан так, чтобы уменьшить конфликты слияния / упростить слияние, если это возможно.
  • Он должен быть полностью документирован (с применением принципа самодостаточности документации).
  • Он должен быть независимым от инструментов

И фраза «это упростит миграцию с .net 4.5 на ядро ​​.net» кажется немного нечестной. Это точно не болевая точка ...

Согласен на 100%. Позвольте мне прояснить, в чем заключались проблемы для нас: единственными трудностями при переносе кодовых баз до сих пор были потеря определенных библиотек классов .NET (глядя на вас, System.Drawing), сдержанность со стороны команд Microsoft в поддержке ядра .NET. (глядя на вас, DocumentDB) и стандартные критические изменения, которые можно ожидать между основными версиями.

Project.json никогда не был проблемой. Фактически, это было одним из преимуществ. То же самое можно сказать о возможности сбросить MSBuild до невидимой детали, которая волшебным образом происходит при нажатии Ctrl + Shift + B.

@neoKushan

  1. Я не люблю XML. Это плохой формат для файлов проекта и конфигурации. Это была плохая идея, когда она была представлена ​​на этапе «XML для всего», и сейчас это плохая идея.
  2. Я считаю, что файлы JSON объединяются намного лучше, чем файлы XML. Я согласен с тем, что это мнение, но оно мое и основано на моем опыте.
  3. Я использую vscode, который не требует и не использует файлы xproj. _That_ - это мой нынешний ландшафт, и я не хочу и не нуждаюсь в файле xproj, который для меня ничего не значит.
  4. Нет, я обсуждаю MSBuild. Я много чего сделал с MSBuild и Team Build. Они никогда не были веселыми, никогда не были легкими, и всегда были связаны с борьбой со свиньей в грязи. Я ненавижу MSBuild, и я определенно не одинок.
  5. MSBuild усложняет даже простые задачи. Я предлагаю вам посмотреть на альтернативы и не ограничиваться MSBuild. Особенно обратите внимание на то, как работают gulp и sbt.

@shederman

Я не люблю XML. Это плохой формат для файлов проекта и конфигурации. Это была плохая идея, когда она была представлена ​​на этапе «XML для всего», и сейчас это плохая идея.

Ничто из этого не объясняет, почему это плохая идея.

Я считаю, что файлы JSON объединяются намного лучше, чем файлы XML. Я согласен с тем, что это мнение, но оно мое и основано на моем опыте.

У меня были кошмарные слияния .json и кошмарные .xml-слияния, я не особенно привязан к ним, когда дело доходит до слияния. По моему опыту, шансы на проблемное слияние увеличиваются с _size_ файла, независимо от формата.

Я использую vscode, который не требует и не использует файлы xproj. Это мой нынешний ландшафт, и я не хочу и не нуждаюсь в файле xproj, который для меня ничего не значит.

Это не значит, что вы не можете пойти и посмотреть текущий файл xproj, чтобы понять, что это такое. Не делая этого, вы делаете то же самое, что засовываете пальцы в уши, закрываете глаза и говорите «Ла-ла-ла».
Другими словами, вы можете расстроиться из-за того, что происходит изменение, и стонать по этому поводу, ничего не достигнув, или вы можете принять участие в реальном разговоре и помочь направить его результат.

Например, еще не решено, станут ли зависимости nuget частью csproj, или они станут nuget.json - здесь есть ваши предпочтения. Когда у вас есть списки зависимостей в файле .json, что остается в csproj? Как часто это будет меняться? Насколько сложно будет _это_ слиться?

Я лично предпочел бы, чтобы все это содержалось в одном файле проекта, но я вижу привлекательность и преимущества отделения nuget от самого проекта. У обоих есть свои плюсы и минусы, и, возможно, лучшее решение - разрешить оба, иметь csproj со списком зависимостей, но также позволить вам вместо этого указывать на файл .json с вашими зависимостями. Лучшее из обоих миров, и все выигрывают за счет некоторой дополнительной сложности самого MSbuild.

Нет, я обсуждаю MSBuild. Я много чего сделал с MSBuild и Team Build. Они никогда не были веселыми, никогда не были легкими, и всегда были связаны с борьбой со свиньей в грязи. Я ненавижу MSBuild и, конечно же, не одинок.

Имея дело с определениями сборки на основе XAML TFS, я могу, по крайней мере, согласиться с вами в отношении (некоторых из них) этого.

MSBuild усложняет даже простые задачи. Я предлагаю вам посмотреть на альтернативы и не ограничиваться MSBuild. Особенно обратите внимание на то, как работают gulp и sbt.

Затем я предлагаю вам перестать выкидывать игрушки из коляски и активно участвовать в обсуждении того, как должна _на самом деле_ выглядеть "новая" структура проекта. Представьте себе будущее, в котором вам придется иметь дело с файлом проекта на основе XML. Как бы вы хотели, чтобы этот файл проекта выглядел на самом деле?

Представьте себе будущее, в котором вам придется иметь дело с файлом проекта на основе XML.

Гм. Итак, я должен представить себе будущее, которого я не хочу, и объяснить вам, как это будет работать? Эм, нет, я так не думаю. Как насчет того, чтобы мы лучше взглянули на некоторые современные, более инновационные системы сборки. ну знаете, те, которые оставили XML в далеком прошлом.

Как насчет:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

Или, может быть

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

Ах да, что xproj вы связаны намного лучше. Красиво, ясно и лаконично. И выразительный, не забывай выразительный. Для чего нужен этот ProjectGuid? И мне нравится 90 символов для установки версии инструмента. А DnxInvisibleContent? Это полезно для моей системы сборки ? Какие файлы не показывать в IDE, которую я не использую?

Я предлагаю вам перестать выкидывать игрушки из коляски

Не хочу :-)

Нет, я закончил. Я долго болтала с Иммо, и я закончил эту битву. У каждого есть свое пристрастие, и никто не хочет слушать возмутительную идею о том, что их путь не может быть идеальным для всех.

[Отредактировано, чтобы убрать раздражительность]

@shederman : вы показываете здесь файлы определения сборки ; Я хочу уйти от определений сборки в качестве определения проекта. Есть место для определения статических деталей о проекте / артефакте, который должен быть сгенерирован, независимо от инструкций о том, как его сгенерировать. То, что он объединяет эти два понятия, является одной из основных проблем при использовании файлов MSBuild в качестве файлов проекта.

Я хочу иметь возможность указать только информацию, необходимую для описания артефакта (ов), который должен быть сгенерирован, зависимостей и инструментальной цепочки, которые будут использоваться, а также компоновку различных элементов, составляющих проект на диске. Все остальное должно быть отдельно. Если вы хотите использовать MSBuild под капотом, продолжайте. То же самое, если вы предпочитаете глоток, бабель или что-нибудь еще. Для меня это то, для чего был создан project.json. (Хотя я не был поклонником возможности определять команды там)

Да, в этом есть смысл. Это одна из тех вещей, которые мне нравились в project.json. Он определял «что», а не «как». Помещая слишком много вещей в один файл, мы делаем файл слишком сложным, особенно если наша IDE глупа. И это не нужно для редакторов и простых IDE.

От простого пользовательского интерфейса, такого как VS Code, особой потребности в системе проектов не возникает. Это все построено. Многие из них декларативны, в них говорится о том, что нужно создавать и о метаданных. Некоторые могут быть императивными, говоря, какие шаги нужно выполнить.

Да, самая большая проблема MSBuilds в том, что он пытается сделать все в одной системе.

Думаю, я не понимаю следующего: покажите мне несколько вариантов использования, которые можно улучшить с помощью MSBuild в качестве системы проектов, а не просто заставить работать project.json. Я этого не вижу. Возможно, мои варианты использования слишком просты, так что покажите мне некоторые.

@shederman В примечаниях к

Итак ... это проект с открытым исходным кодом, и я знаю, что Microsoft - это «сильные мира сего», но если это так важно для людей, тогда - и я понимаю, что задаю здесь невежественный вопрос - сколько времени Потребуется затратить / усилие / энергию, чтобы позволить .NET Core продолжать использовать project.json в качестве альтернативы MSBuild? Если достаточно людей вносят свой вклад и код достаточно хорош, то почему бы MS не принять его в этот проект? Отчасти красота (и недостаток) открытого исходного кода заключается в угрозе разветвления кода, если основной сопровождающий откажется от слишком многого из того, что предлагают другие. Часть кода, являющегося открытым исходным кодом, заключается не только в том, чтобы на него смотреть, но и в том, чтобы изменять и улучшать.

Я лично считаю, что это изменение связано с Xamarin и касается планов на будущее. Кроме того, на недавних выступлениях, я думаю, я слышал, как они говорили, что хотят, чтобы создание консольных приложений было первоклассным гражданином. Помните, что изначально новый .NET (ASP.NET 5 + DNX) был ориентирован на создание веб-приложений, теперь речь идет о большем. Все это произошло сравнительно недавно, команды .NET и ASP.NET объединились, а также была приобретена Xamarin. Они пришли к выводу, что им нужна лучшая система проектов для поддержки этих нескольких сценариев (и новых сценариев будущего, о которых я не буду здесь рассуждать), и они также хотят в ближайшее время выпустить .NET Core. Что делать? Полностью игнорировать существующий ранее MSBuild, который уже может обрабатывать все, что требуется, и начинать с нуля? Извините, я знаю, какой путь выбрал бы.

Похоже, что большая часть беспокойства связана с слиянием, НО если файл проекта не содержит имен файлов в проекте, и если зависимости помещены в отдельный файл конфигурации, проблема слияния должна исчезнуть, поскольку файлы проекта должны затем измениться относительно нечасто.

Просто мое мнение

Проблема слияния - это только одна проблема. Другое дело - уйти от MSBuild. Один безумный результат этого сценария состоит в том, что теперь они собираются потратить время и усилия на перенос MSBuild на Linux и OSX! Представьте себе, что.

Я понимаю их причины, но их причины совершенно не работают для меня и не работают для многих людей. Мы сделали инвестиции, основываясь на твердой гарантии того, в каком направлении они движутся, и они вернулись к нему с нулевой подотчетностью и не более чем указанием на то, что, возможно, им следовало бы лучше разъяснить свое решение. Они принимают решение о project.json на основе крайних случаев, которые поддерживает MSBuild, и того, насколько сложно будет поддерживать эти крайние случаи. Что ж, это означает, что он _ никогда_ не перестанет использоваться, потому что никто в здравом уме не поддержит все эти крайние случаи. Конечно, никому, кто занимается проектами ASP.NET, не нужны эти крайние случаи.

Разветвление - это возможность, но, учитывая, насколько все масштабно и интегрировано, сложно даже подумать об изучении соответствующего кода. Реальность такова, что на самом деле это не проект с открытым исходным кодом, это проект Microsoft, и они приняли корпоративное решение без нашего участия, и мы должны просто принять его и принять. Мне было разъяснено, что практически нет никакой возможности, чтобы они _ когда-либо_ пересмотрели, независимо от того, какое сопротивление было.

Итак, либо мы потратим усилия и создадим форк системы сборки project.json, либо переключимся на другую систему сборки (FAKE?), Либо вы откажетесь от нее, либо воспользуетесь другой платформой. Думаю, я перечислил здесь все варианты.

@shederman MSBuild является открытым исходным кодом с начала 2015 года, и сборки передаются на OSX / Ubuntu, поэтому я не думаю, что это так много работы, как вы могли бы подумать для переноса (https://github.com/Microsoft/msbuild) , просматривая репо, похоже, что OSX, например, строила нормально еще в марте.

О, Боже. Меня беспокоит, _должны_ ли мы это делать, а они пошли и сделали это ...

Почувствуйте себя кем-то, кто наблюдает, как чудовище Франкенштейна уносится вдаль. Заинтересовано, заинтриговано, обеспокоено и более чем немного противно :-)

@darrelmiller В примечаниях к

Действительно? Люди до сих пор так делают? Я имею в виду, что раньше я делал это для AssemblyInfo.cs, а в Средние века мы помещали наш ключ строгого имени в общий исходный файл.

Хорошо, что это случай использования, но теперь я действительно хочу услышать случай использования для случая использования. Заинтриговано.

@shederman

Гм. Итак, я должен представить себе будущее, которого я не хочу, и объяснить вам, как это будет работать? Эм нет, я так не думаю

Все, что вам нужно сделать, это принять XML вместо JSON, чтобы увидеть, какие могут быть преимущества, но вы не желаете играть в эту игру, потому что все, что вам нужно, - это говорить о том, насколько плох XML, не объясняя, почему .

О, Боже. Меня беспокоит, стоит ли нам это делать, а они пошли и сделали это ...

Они «уходят и делают это» буквально в течение нескольких лет. Они говорили об открытом исходном коде .net много лет назад, они дали дорожные карты и ясно дали понять, что в конечном итоге речь идет о запуске на любой платформе для любого варианта использования.

Вы очень расстроены этим изменением, и я подозреваю, что большинство людей, недовольных этим изменением, - все веб-разработчики, но это лишь небольшая часть экосистемы .net, существует огромная экосистема сервисов, мобильных и облачных разработчиков, у которых есть огромные библиотеки кода, которые они хотят перенести на ядро ​​.net. Нравится вам это или нет, но в настоящее время project.json не работает для всех этих моделей. Вы говорите «заставить его работать», но в итоге вы получите еще один беспорядочный файл проекта, за исключением того, который не имеет очевидной и четко определенной структуры и, что еще хуже, без комментариев. Этот последний пункт является достаточной причиной, чтобы переосмыслить project.json.

Ах да, этот xproj, на который вы ссылались, намного лучше. Красиво, ясно и лаконично. И выразительный, не забывай выразительный.

По крайней мере, вы наконец посмотрели на это. Потребовалось всего 72 комментария в этом выпуске, прежде чем вы даже забеспокоились? Я все время говорю вам, но вы этого не понимаете: вместо того, чтобы жаловаться на ужасный MSBuild, поговорите о том, почему он ужасен .

Проблема слияния - это только одна проблема. Другое дело - уйти от MSBuild.

Почему это вообще проблема? Вы ненавидите MSBuild, мы это понимаем, но что вы ненавидите в MSBuild, кроме того факта, что _dares_ использовать XML?

Один безумный результат этого сценария состоит в том, что теперь они собираются потратить время и усилия на перенос MSBuild на Linux и OSX! Представьте себе, что.

Ты прав! Будет ужасно иметь возможность разрабатывать любое приложение .net на любой платформе, которую вы хотите, используя любую IDE, которую вы хотите. Подумайте о детях!
Как смеет Microsoft тратить время на создание открытых исходных кодов для своей работы и перенос своих инструментов на другие платформы вместо того, чтобы вкладывать средства в собственные технологии с закрытым исходным кодом?

Я понимаю их причины, но их причины совершенно не работают для меня и не работают для многих людей.

Но, может быть, они работают на гораздо большее количество людей, чем вы?

Мы сделали инвестиции, основываясь на твердой гарантии того, в каком направлении они движутся, и они вернулись к нему с нулевой подотчетностью и не более чем указанием на то, что, возможно, им следовало лучше сообщить о своем решении.

Какое _направление_ вы имеете в виду? Целью всегда было .net повсюду. «Любой разработчик, любое приложение, любая платформа» - это мантра дня, и в этом изменении нет абсолютно ничего, что могло бы повлиять на это. Они четко заявили, что их цели - сделать файл проекта небольшим, простым, читабельным и доступным для редактирования человеком без IDE. У вас ничего не забирают. Возможно, вам придется иметь дело с небольшим количеством XML, большой возглас, если это означает, что .net - это первоклассный интерфейс для мобильных устройств, облачных вычислений и Интернета, тогда оно того стоит.

Они принимают решение о project.json на основе крайних случаев, которые поддерживает MSBuild.

Это далеко за пределами _edge_ случаев, смехотворно даже предполагать, что project.json почти идеален.

Конечно, никому, кто занимается проектами ASP.NET, не нужны эти крайние случаи.

Я полагаю, что в этом суть проблемы: вы не заботитесь ни о ком, кроме себя, разработчика asp.net. Достаточно справедливо, но я еще раз говорю вам: примите то, что другие разработчики имеют значение, и вместо того, чтобы просто вскидывать руки вверх, работайте над тем, чтобы сделать эту систему лучшей из возможных. Это не означает создания произвольного синтаксиса для совершенно другой разметки, это означает признание того, что картина больше, чем вы, и работа с другими, чтобы сделать ее удобной для всех.
Как я постоянно говорю, если в nuget.json перечислены все ваши зависимости, что останется? В чем проблема с определением некоторых довольно статичных полей в именованных элементах XML?

На самом деле это не проект с открытым исходным кодом.

Как говорили другие, быть открытым исходным кодом не означает отказываться от нескольких жалобщиков. Они принимают запросы на вытягивание, иди напиши что-нибудь получше.

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

Хорошо, поэтому я в основном читаю это как «Я не понимаю большей картины и не хочу понимать большую картину, но я все равно буду жаловаться, потому что это влияет на мой маленький пузырь, полностью игнорируя последствия. мой пузырь имеет на других ".

Итак, либо мы потратим усилия и создадим форк системы сборки project.json, либо переключимся на другую систему сборки (FAKE?), Либо вы откажетесь от нее, либо воспользуетесь другой платформой. Думаю, я перечислил здесь все варианты.

Или ... я имею в виду, что это просто сумасшедшая, нестандартная мысль, но вы можете попробовать внести что-то конструктивное в беседу.

Возвращаясь к теме ....

Я подумал об этом больше и теперь склоняюсь к тому, чтобы project.json превратился в nuget.json, сохраняя управление зависимостями в том виде, в каком оно есть сейчас. Теперь он работает хорошо, intellisense уже здесь, и он совместим с такими вещами, как gulp и npm.

Пусть csproj просто определяет статические части.

Однако обратная сторона этого подхода, которую я вижу, заключается в том, что я не уверен, насколько хорошо это будет работать при нацеливании на несколько фреймворков, я действительно не чувствую, что имеет смысл помещать это в nuget.json, но nuget.json - это все еще нужно будет знать об этом.

project.json - это не просто файл json.
csproj - это не просто файл XML.

ИМХО многие люди, как и я, были взволнованы, увидев Microsoft, а точнее команду Asp.Net,
освобождая себя от очень старого устаревшего кода / концепций / систем / инструментов / внешнего вида / ...

Это дало нам «надежду»!

Я разрабатываю Asp.Net с самых первых предварительных версий. Я больше всего люблю с ней работать. Но через 15 лет
«старые» вещи, такие как XML, кажутся действительно очень тяжелыми и устаревшими. Восприятие важно.

Без XML и хотя бы с использованием JSON мое «счастье для разработчиков» намного больше.
Я могу работать с вещами, которыми решил воспользоваться весь остальной мир. Моя среда IDE отдает предпочтение этим вещам по сравнению с устаревшими форматами.
Мне больше не нужно платить «налог на угловую скобку».

Удаление project.json не представляет большого труда, но выполнение его за закрытыми дверями почти в последний момент мгновенно убивает эту «надежду».

Внезапно это больше не похоже на проект с открытым исходным кодом.

к сведению: "Asp.Net Core" имеет много фантастических возможностей. Мне это больше всего нравится.
Команда Asp.Net великолепна, и я очень горжусь тем, что являюсь разработчиком Asp.Net.

Но мне больно. Может, я не один такой.

Только мои 2 цента.

Я думаю, мы почти все можем согласиться с тем, что msbuild (особенно то, как его использует VS) не идеален, и хотя я был в восторге от project.json, он больше касался исправления MS многих моих болевых точек и, честно говоря, до тех пор, пока они делают. Я, наверное, не особо беспокоюсь о том, как они это сделали.

  • Слияние csproj работает не так хорошо, мне приходится вручную исправлять неработающее слияние каждые две недели. Здесь очень поможет удаление списка файлов из csproj.
  • Ссылки NuGet и ссылки на проекты не всегда совпадают, опять же, это может быть связано с неработающими слияниями. Так или иначе, диагностировать и исправлять раздражает.
  • Иногда мне нужно подключиться к процессу сборки (не знаю, как это должно работать в project.json), но необходимость выгрузки / загрузки делает отладку сценария сборки болезненным процессом.

Если они найдут способ исправить эти 3 элемента, я, вероятно, не стану так сильно жаловаться на файлы csproj.

@neoKushan

все, что вы хотите сделать, это поговорить о том, насколько плох XML, на самом деле не объясняя, почему

Не совсем честно, еще хочу поговорить о том, насколько плох MSBuild :-)

Я уверен, что на самом деле _have_ сказал, почему мне не нравится XML для файлов сборки, но позвольте мне еще раз попробовать. XML многословен, уродлив, он лучше подходит для инструментов, чем для ручного редактирования, и мне не нравится объединять его. Он использовался для MSBuild, потому что тогда отрасль считала, что XML можно использовать для всего. С тех пор мы двинулись дальше. Ну кое-где.

еще хуже - без комментариев

Я считаю, что несколько человек предложили здесь альтернативы. HJson - лишь один из вариантов. Ура! В конце концов, нам не нужно это переосмысливать ;-)

Вы очень расстроены этим изменением

Честно говоря, меня больше всего расстраивает то, как это изменение было внесено в закрытом помещении без учета или взаимодействия с сообществом, которое приняло предыдущую очень твердую поддержку project.json за чистую монету. Мальчик, не повторю ЭТОЙ ошибки снова!

Не поймите меня неправильно, мне не нравится XML, не нравится MSBuild. Но терпеть не

Я подозреваю, что большинство людей, недовольных этим изменением, - это веб-разработчики.

Умм, да, это потому, что они единственные разработчики, которым вы предложили project.json. Из других новостей, разработчики Swift также не расстроены этим решением. Я имею в виду, подумайте, что вы здесь говорите:

  1. Только веб-разработчики получили эту новую функцию
  2. Многие из них очень расстроились, когда мы его забрали
  3. Больше никому не нужно это использовать
  4. Люди, которые не использовали его, не расстроены, что его забрали
    следовательно, все другие разработчики этого не захотят.

Я думаю, вам нужно взглянуть на качество вашего мышления, и это то, что я пытался допросить довольно долгое время, но ничего не добился. Отсутствие информации о мышлении и тот факт, что соответствующие стороны замолчали, указывает мне на то, что это мышление могло быть подозрительным.

А что вы подразумеваете под «веб-разработчиками»? Вы думаете о каком-нибудь маленьком веб-сайте для небольшой компании? Как насчет набора микросервисов, поддерживающих бизнес по управлению активами с десятками миллиардов долларов под управлением. Конечно, там тоже есть сайт. Но это около 10% системы. О, и да, он на самом деле тоже нацелен на облако, так что, возможно, мы на самом деле говорим «облачные разработчики».

Похоже, вы даже не понимаете, как и кем используется технология, по которой вы принимаете опрометчивые решения.

что вы ненавидите в MSBuild, кроме того факта, что он осмеливается использовать XML

Это слишком сложно
Это несоответствие импеданса, толкающее логику вывода в ситуации, когда люди в основном имеют дело с императивной или декларативной логикой.
Боже мой, ты действительно смотрел файлы MSBuild? Хорошо, извините, вы сказали, помимо использования XML ;-)
То, как объявляются свойства и элементы, противоречит интуиции для тех, кто не использует его регулярно.
Он используется как универсальный инструмент, который пытается выполнять задачи, которые должны выполняться в сценариях. Молоток, гвозди.
В большинстве случаев все, что он делает в большом файле, может быть выражено не более чем в 3 строках сценария.
Мусор VS, который в него извергается. Я слышал, что это будет исправлено. Жду с некоторым трепетом, чтобы увидеть, не порежется ли и это. Как упоминалось выше, сейчас я немного настойчиво отношусь к обещаниям.

Что ты так любишь ? И, что наиболее важно, готовы ли вы согласиться с тем, что другие могут не разделять ваши взгляды? Если да, то можете ли вы признать, что подход «под одну гребенку» может быть неправильным?

В каком направлении вы имеете в виду

project.json - это основа нашего нового подхода к проекту - это то, что было сообщено. Мы вложили реальные деньги, время и усилия, взяв на себя это обязательство.

Но, может быть, они работают на гораздо большее количество людей, чем вы?

Может быть, действительно так. Но если да, то где доказательства этого? Я попытался исследовать мышление, принятие решений и доказательства, которые использовались при этом, и ничего не получил ни от кого. Насколько нам известно, несмотря на все представленные доказательства, вы могли потрясти шар Magic 8.

Никто не знает, сколько думают так или иначе. На самом деле я единственный, кого я знаю, который действительно пытался это выяснить.

Вы не заботитесь ни о ком, кроме себя, разработчик asp.net

Не очень хорошо. На самом деле я говорю, что утверждаю, что новое направление работает для всех вариантов использования, и я поднимаю руку и говорю, что это не работает для меня. Ты едешь грубо обутый через всю оппозицию. Я тот, кто спрашивает людей, что они думают, а не РС.

Я ни разу не сказал «полностью избавиться от MSBuild и применить мой процесс сборки ко всем другим разработчикам». Вы тот, кто говорит: «Полностью избавьтесь от project.json и примените MSBuild для всех разработчиков». Во всех превью у нас было две системы сборки, и мы остались довольны. Веб-разработчики были довольны, а разработчики, не работающие в Сети, были довольны.

Мы можем обсудить, насколько это осуществимо, а может быть, и нет, но мы не знаем , потому что с нами никогда не консультировались и не взаимодействовали.

Вы действительно любите аргументы исключенного третьего.

Они принимают запросы на вытягивание

Действительно? Если бы мы отправили запрос на перенос, который оставил инструмент сборки, не основанный на MSBuild, в основных функциях инструментов, который читает только project.json, вы бы включили его в структуру? Действительно?

Хорошо, я в основном читаю это как ...

Ничего себе, вы много читаете об этом. Черт возьми, если бы я читал, как ты, я бы никогда не дочитал книгу. И это было бы совсем не то, что написал автор.

Скорее попробуйте: «Я не полностью понимаю общую картину, и я рассматриваю усилия и время, которые потребуются для этого. Было бы намного лучше, если бы у нас была помощь существующих разработчиков в доставке такой значительной доли их сообщества, но я думаю, если им все равно, чего хотят их пользователи, нам, возможно, придется пойти по этому пути ».

Черт возьми! Я читаю как ты! За исключением того, что на самом деле это немного лучше соответствует исходному тексту, чем ваши несколько истерические интерпретации.

вы можете попробовать внести что-то конструктивное в беседу.

На самом деле я думал, что говорю конструктивно. После того, как я преодолел первоначальный шок, я попытался выяснить, на чем основывалось это решение. Я попытался выяснить, каков был процесс принятия решения. Я попытался исследовать качество мышления, лежавшего за этим. Когда мне сказали, что этого хотят большинство разработчиков, но не было предоставлено никаких доказательств, подтверждающих это утверждение, я фактически спросил их, кто _но_ никто_ в команде не сделал этого.

Что я получил? Препятствие, оскорбления и уклонения. Итак, скажите мне, почему вы считаете неконструктивным спрашивать, делал ли кто-то важное решение, затрагивающее миллионы людей, свою домашнюю работу? Считаете ли вы конструктивным или подозрительным, когда указанные люди отказываются показывать тетрадь с домашним заданием?

Я имею в виду, что на самом деле это вероятные сценарии:
1) Вы приняли решение на основе полного набора отзывов и информации, и решение, безусловно, лучший вариант для дальнейшего продвижения. Если так, я бы заткнулся, обещаю. Я считаю, что такая ситуация маловероятна из-за уровня сопротивления, которое вы получили, и того факта, что вы скрываете доказательства и принимаемые решения.
2) Вы приняли решение, основываясь на частичных взглядах, но на лучшем, что у вас было на тот момент. Я бы сказал, что правильным ответом будет повторное рассмотрение решения и запрос мнений, которые вы упустили. Я считаю это наиболее вероятной ситуацией.
3) Вы приняли решение неверно или на основании неверной информации. В этом случае вы должны снова открыть решение и запросить у сообщества. Я действительно не думаю, что это такая ситуация, потому что, как бы вы мне не поверили, я безмерно уважаю разработчиков DotNetCore. Все они.

И знаете, что, если вы снова откроете решение, запросите мнения, и решение будет принято таким же образом, как и оно, то в чем тогда вред? И если после запроса мнений вы поймете, что некоторые из ваших решений были ошибочными, и исправите их, разве это не лучше ?

Вау, серьезно. Можем ли мы положить этому конец?

Простой вопрос: собираетесь ли вы принять оппозицию и пересмотреть решение на основе новой информации?

Или вы собираетесь продолжать просто намекать на то, что люди, которые с вами не согласны, сумасшедшие, глупые, неквалифицированные, _неинформированные_ или иным образом неспособные придерживаться информированного, действительного мнения?

Предложение: вилка Microsoft для поддержки устаревших клиентов msbuild csproj. #carryOnAsNormal

Я также являюсь давним разработчиком .Net, работал с превью версии 1.0 до того, как маркетинг даже придумал имя .Net. Не заблудившись в сорняках, вот мои два цента.

Я мог бы прожить остаток своей жизни, не видя ни одного конфигурационного файла xml, и быть совершенно счастливым.

Мне не нужна конфигурация xml. В любом месте. Всегда.

Меня не волнует, исправит ли команда все болевые точки csproj; если это все еще конфигурационный файл xml, когда вы закончите, меня это не интересует. Вы также можете просто оставить систему проектов .net 4.5.

Что касается MSBuild ... MSBuild может погибнуть в огне.

Я понимаю, что это мощно, и вокруг него существует множество инструментов, но за пределами MS только серьезные глубокие эксперты по MSBuild действительно знают, что он делает и как работает. Каждый раз, когда мне приходится вносить какие-либо изменения в процесс сборки, я теряю 3-5 дней моей профессиональной жизни. Я редко могу получить что-либо, даже тривиальные вещи, такие как просто включение пустой папки в вывод, чтобы работать прямо в VS, публикации VS и на моем сервере CI одновременно.

Я понимаю ... если у вас нет времени на создание хорошей замены MSBuild для временного интервала asp.net core 1.0, тогда конечно ... придумайте способ продолжить использовать MSBuild до asp.net core 2.0 цикл; но, по крайней мере, продолжайте работать в направлении замены этой какашки чем-то, с чем остальные из нас могли бы работать.

А пока постарайтесь сохранить как можно большую часть конфигурации в json. Меня особо не волнует, является ли это project.json или что-то новое и лучшее. Если необходимо, попросите инструментальные средства генерировать устаревшие файлы MSBuild на лету, когда / при необходимости - вставьте их в какую-то подпапку или что-то в этом роде.

Чего я не хочу, так это того, чтобы моя файловая система выглядела так:

  • bower.json
  • package.json
  • nuget.json
  • все-остальное.json
  • microsoft-old-ass.xml.csproj

Кроме того, не могли бы вы исправить ограничение длины пути в 260 символов ... пожалуйста ... да, я знаю, что это имеет прямое отношение к окнам, но серьезно ... это 2016 год.

PS. Если вы собираетесь вести игнорируя оппозицию, пожалуйста , вы можете предоставить следующие:

  • Как мы получим доступ к каналам Slack для разработчиков инструментов сборки
  • Высокоуровневое представление о текущей архитектуре и коде, а также о том, где будут внесены изменения для перехода в MSBuild / xproj, чтобы мы могли спланировать наш подход, чтобы сохранить нужные нам биты и хорошо интегрироваться.
  • Гарантия того, что запекание запросов на вытягивание в инструментах на основе project.json будет принято, если они соответствуют критериям качества.
  • Гарантия того, что при соблюдении критериев качества мы можем включить поддержку «dotnet build» для полного проекта project.json, а также простых шаблонов ASP.NET и, возможно, некоторых шаблонов для более стандартных типов проектов.

«Будьте конструктивны», «не участвуйте, не получайте голоса». Что ж, вы получаете то, о чем просите ...

@ Mike-EEE, хотите выполнить сериализацию Xaml для SimpleUseCaseBuild?

Прочитав все это, я пришел к таким выводам:

  • В project.json внесено много улучшений. Ничего из этого было бы невозможно, если бы ядро ​​.net и asp.net было бы привязано к устаревшему коду и инструментам.
  • project.json (и json) не идеален
  • xml vs json vs anyserializationlanguage стерильны. Было бы интереснее обсудить, как использовать их для решения основных задач .net.
  • возврат к msbuild возвращает наследие, и это, вероятно, означает, что мы больше не увидим улучшений в системе проектов, потому что команды .net, вероятно, потеряют часть своей свободы

Я надеюсь, что команды .net сделают глубокий вдох, остановят это немного, соберут отзывы (и рассмотрят принятие и восприятие этого нового стека) и бросят вызов подходу msbuild (который может быть не таким плохим, как некоторые из нас думают) с помощью некоторые альтернативы. Думаю, надо спешить.

LOL @shederman, во что ты меня сейчас

xml vs json vs anyserializationlanguage стерильны. Было бы интереснее обсудить, как использовать их для решения основных задач .net.

Да, для меня важна модель поддержки, используемая для описания проектов и / или того, что они делают, и некоторые из этих разговоров касались этого. Я хотел бы увидеть улучшенную модель проекта / api, которую было бы легче описывать и с которой было бы легче работать (независимо от формата, в котором она описана - хотя да, я делаю: heart: my Xaml!). У меня есть открытое обсуждение репозитория MSBuild здесь (https://github.com/Microsoft/msbuild/issues/613) по этому поводу, а также по системе проектов Roslyn (https://github.com/dotnet/roslyn-project -system / issues / 37), если интересно.

Здесь много действительно замечательных моментов, и я лично копаю энергию, «неконструктивную» или нет. Я думаю, что каждый здесь стремится улучшить MSFT и извлечь максимум из того, что создается. : +1:

Мои 2 цента:

Я считаю, что это изменение обсуждают два типа людей:

  • разработчики, которые использовали VS и .NET для создания _различных_ проектов и должны поддерживать эти проекты в течение долгого времени
  • разработчики, которые не имеют такого багажа и хотят новую, чистую и модную кроссплатформенную платформу ASP.NET Core.

Лично я отношусь к первой категории, поэтому я хочу, чтобы новое ядро ​​ASP.NET было максимально совместимо с другими типами проектов VS, а переход на «старое» решение csproj / msbuild для меня - это победа (+ my команда и, вероятно, многие другие разработчики). Таким образом переход будет более плавным и четким. Может, люди из второй категории со мной не согласятся (или им все равно).

Единственная серьезная проблема, которую я сейчас вижу, - это то, как пакеты NuGet определяются и ссылаются на них. Больно поддерживать файлы packages.config и csproj (как @ cwe1ss, предложенное в https://github.com/aspnet/Home/issues/1433#issuecomment-218519705). Кстати, это был один из самых конструктивных комментариев в этой теме ...

Что касается священной войны XML / JSON ... ИМХО, XML лучше для ручного редактирования, чем JSON. XML поддерживает комментарии и дает больше контекстной информации, когда вы просматриваете его. JSON лучше подходит для данных, а не для файлов конфигурации. Слияние одинаково хорошо и плохо для обоих форматов, оно зависит исключительно от контента. Если бы ссылки на проекты были отделены от текущих файлов csproj, слияние также стало бы намного проще ...

@Funbit, пытаясь разделить людей на категории, не поможет. И я не вписываюсь ни в одну из ваших категорий. Я разработчик asp.net с бета версии v1. Я почти перестал им быть 2 года назад, но ядро ​​.net вернуло меня, потому что это был чистый лист и лучшее из мира .net и узлов.

Я хочу, чтобы ядро ​​.net пользовалось успехом, а не старым корпоративным техно без принятия и без сообщества.

Со своей стороны, меня не особо волнует это решение, меня не особо интересует XML, и чтобы украсть цитату: «Фигурные скобки лучше, чем угловые», но это не особо беспокоит меня, возвращаясь к csproj / msbuild - я гибкий, я могу справиться.

Я хотел бы повторить некоторые из комментариев @shederman :

Реальность такова, что на самом деле это не проект с открытым исходным кодом, это проект Microsoft, и они приняли корпоративное решение без нашего участия, и мы должны просто принять его и принять. Мне было разъяснено, что практически нет никакой возможности, чтобы они когда-либо пересмотрели свое мнение, независимо от того, какое сопротивление было.

и

Честно говоря, меня больше всего расстраивает то, как это изменение было внесено в закрытом помещении без учета или взаимодействия с сообществом, которое приняло предыдущую очень твердую поддержку project.json за чистую монету. Мальчик, не повторю ЭТОЙ ошибки снова!

Меня это _ беспокоит, потому что Microsoft сделала большой выбор в пользу .NET с открытым исходным кодом и хотела действительно вовлекать и работать с сообществом, получать их отзывы и быть хорошим «членом» (партнером?) Сообщества. Но такие вещи действительно сводят на нет все эти усилия и придают экосистеме .NET такое "бургомистское" ощущение, что /. сообщество пометило это в течение многих лет.

Чтобы быть справедливым по отношению к Microsoft, они не единственные, кто делает подобные вещи с корпоративным спонсируемым проектом; помните раскол в сообществе nodejs (который вызвал форк io.js)? Но я думаю, что когда это Microsoft, все намного хуже.

Это было намного больше, чем предполагалось изначально.

1ajq1

Это было намного больше, чем предполагалось изначально.

@MaximRouiller ты вообще разработчик, братан ??? :улыбка:

@ Mike-EEE Верно. Я ожидал жарких споров, но видел слишком много личных нападок. :разочарованный:

необходимость обмениваться исходными файлами между проектами

@darrelmiller Для меня это звучит пугающе, потому что, похоже, это означает, что список файлов в .csproj возвращается.

@lokitoth Вероятно, нет причин, по которым связанные файлы также не могут использовать подстановочные знаки.

@MaximRouiller Я тоже виноват в том, что слишком @shederman умеет бросать! Ха-ха. Между прочим, я собирался сказать, что @shederman представляет мое внутреннее кодирующее животное, но это было до того, как я узнал, что существует @CodingGorilla. :смеющийся:

Я думаю, нам нужно напоминать себе, что то, что мы делаем, - это действительно тяжелая работа, и вот тогда она срабатывает! Добраться туда еще сложнее. По моему опыту работы с Silverlight (да, я сгорел из-за этого, так что я знаю, откуда взялся @shederman ), это помогло мне понять, что, возможно, я не знаю _ всего_ (или даже _ что-нибудь_ временами кажется!) и сохранять непредвзятость в отношении вещей. Я все еще терплю неудачу. Даже когда я увидел инициативу project.json, я приложил все усилия, чтобы указать на создаваемое ею разделение, но, возможно, при этом был слишком резок с людьми здесь, в репозитории.

В любом случае, всегда лучше сделать глубокий вдох, (попытаться) проявить скромный дух и напомнить себе, что мы в одной команде, даже если эта команда сейчас разделена на «веб» и «родной» лагерь. Некоторое время это может показаться отстойным, но то, о чем мы здесь говорим, будет служить нам долгое время - даже десятилетие или даже больше. Давайте сосредоточимся на долгосрочном подходе, одновременно проявляя сочувствие к другим и их происхождению.

Хорошо ... хватит проповедей и ура на день. : stuck_out_tongue: Вернемся к нашему регулярному фестивалю!

Для меня это звучит пугающе, потому что, похоже, это означает, что список файлов в .csproj возвращается.

Кроме того, я единственный человек на планете, который ценит эту особенность? : stuck_out_tongue:

Для меня это звучит пугающе, потому что, похоже, это означает, что список файлов в .csproj возвращается.

Кроме того, я думаю, единственный человек на планете, который ценит эту функцию? : stuck_out_tongue:

@ Mike-EEE Да, думаю, да. :подмигивание:

Основной вариант использования связанных файлов - это нацеливание на несколько платформ. Это одна из особенностей project.json, которую я действительно хочу сохранить. Не думаю, что я видел какие-либо конкретные комментарии об этой возможности, но было бы неплохо, если бы команда могла подтвердить свое намерение воссоздать это в msbuild.

@shederman умеет закидывать!
😆

Я стараюсь. Я очень надеюсь, что никого не оскорбил. Я очень старался идти только за спорами.

Меня особенно раздражают ехидные личные оскорбления, так что любой, кто спорит против меня, НЕ способ заткнуть меня. 😉 А таких было довольно много.

Мне интересно узнать о вариантах использования для редактирования файлов csproj. Мой опыт показывает, что мне приходилось редактировать файлы csproj только тогда, когда nuget что-то напутал или путь подсказки был сломан. Для добавления новых шагов в процесс сборки я всегда использовал файл build.proj более высокого уровня, который запускал моя система CI. Я никогда не использую файлы .sln в своей настройке CI.

Является ли основной целью людей редактировать файлы csproj для добавления шагов BeforeBuild и AfterBuild, которые они хотят выполнять при отладке в Visual Studio?

@ Mike-EEE Может быть; Я в основном помню, что это была королевская боль в заднице при работе с проектами с очень большим количеством файлов (например, Expression Blend, Visual Studio XAML Designer и т. Д.) До такой степени, что мы заменили его для выбора подстановочного знака - что VS делает не знаю, как правильно работать, а это значит, что каждый раз, когда я добавляю файл, мне приходится перезагружать проект (или сталкиваться с ошибкой «этот файл уже добавлен» при сборке)

Что вам на самом деле нравится в этой «функции» (не обмениваться файлами между проектами, что, очевидно, полезно, но о том, что VS работает правильно только тогда, когда каждый файл указан отдельно)?

Что вам на самом деле нравится в этой «функции» (не обмениваться файлами между проектами, что, очевидно, полезно, но о том, что VS работает правильно только тогда, когда каждый файл указан отдельно)?

По общему признанию, это плохая привычка, но мне нравится удалять файлы из своего проекта, когда я занимаюсь рефакторингом. Или даже с исторической точки зрения. Если я знаю, что работаю над чем-то, что мне может понадобиться позже, я сохраняю это на диске, но удаляю из проекта. Конечно, это загрязняет репо / контроль исходного кода (см .: плохая привычка), но мне нравится такой контроль. Потому что теперь, когда мне нужен этот файл, мне не нужно возиться с историей репо (как найти эту историю удаленного файла - слишком много работы!), Я просто "показываю все файлы" и снова добавьте его в свое решение. Мгновенная история. :улыбка:

Мне интересно узнать о вариантах использования для редактирования файлов csproj

Для .csproj (все это я делал, а для большинства - несколько раз)

  • Если вам нужно сослаться на типы UWP из настольного приложения
  • Если вам нужно исправить VS, ломающие вещи с помощью NuGet (особенно при добавлении файлов a.targets и .proj / .props)
  • Если вам нужно изменить макет сгенерированного вывода
  • Если вы выполняете рефакторинг проектов и переименовываете сборки
  • Если вы делаете большой рефакторинг, который влияет на множество файлов
  • Если у вас возник конфликт слияния из-за того, что несколько человек работают в одном проекте, и вы не используете подстановочные знаки
  • Если вам нужно понять, почему сборка внезапно не работает (Edit: я должен был указать - это больше похоже на то, «почему мне нужно, чтобы он был читабельным и« самодостаточным »»)
  • Если вам нужно отладить конфликты версий сборки из-за надоедливых зависимостей
  • Если вы пытаетесь добавить «связанный» (общий) файл

Для project.json

  • Создание файла с нуля вручную (критически важно)
  • Добавление / удаление пакетов NuGet
  • Изменение целевой структуры
  • Изменение версии выходного пакета

@shederman Я понимаю, что вы расстроены, но когда вы отвечаете

Действительно? Люди до сих пор так делают? То есть я делал это для AssemblyInfo.cs, а еще в темные века

Вы задаете тон. Лицом к лицу разговаривать - это нормально, но в такой среде это обычно открывает двери для целого ряда комментариев, основанных на эмоциях, которые поляризуют разговор и затрудняют сосредоточение внимания на важных моментах. Я знаю, что трудно удержать эмоции от этих обсуждений (на моем языке много следов от укусов ;-)), но мы действительно должны постараться, чтобы обсуждение оставалось полезным.

@ Mike-EEE Не могли бы вы сделать то же самое (не перечисляя каждый файл), используя атрибут / шаблон Exclude ? Для записи, я часто делаю то же самое, это очень удобно, когда вы просто хотите что-то быстро устранить, не выполняя цикл фиксации / отката.

Для протокола, мне действительно нравится предложение @Mike-EEE в отношении использования Roslyn и наличия файла проекта в виде сериализованного AST. Но только в том случае, если нам удастся сделать так, чтобы с ним было одинаково легко работать, используя только блокнот. (Да, я имею в виду блокнот, а не блокнот ++ или что-то еще более продвинутое: это «дымовой тест» на удобство использования редактируемого человеком формата файла)

@CodingGorilla Я открыт для этого. Я бы предпочел, чтобы инструменты помогли мне в этом (определите для меня шаблон, а не выясняйте, как это сделать - если я чувствую, что снова работаю с DOS, ВСЕ ПОТЕРЯЮТ !!). Я должен получить тот же опыт, что и сейчас.

Так что, по сути, мы рассматриваем модель отказа, а не подписку.

Для тех, кто хочет редактировать файлы проекта без выгрузки .... https://twitter.com/migueldeicaza/status/730978470734401536

Для тех, кто хочет редактировать файлы проекта без выгрузки ....

@darrelmiller, что я здесь вижу ... предлагаете вместо этого использовать Xamarin Studio? Да, этот бизнес по разгрузке / погрузке / рабочий процесс / опыт - САМЫЙ НАИБОЛЬШИЙ! Он существует с 2003 года, хех.

Я поддерживаю идею о том, что конечный файл должен быть легко редактируемым и читаемым с помощью стандартного текстового редактора (например, блокнота), независимо от формата.

Я также думаю, что лучшие инструменты устранят множество проблем, связанных с текущим csproj. VS - не лучший пример, и я думаю, что опыт, который дает вам VS, - это то, что многие люди действительно ненавидят в системе проектов MSBuild.

@ Mike-EEE Ответ на комментарий Мигеля был от Дэвида Кина, который работает над новой системой проектов. Команда знает, что VS тоже должна уметь это делать.

@ Mike-EEE Думаю, моя особенность в том, что я могу справиться со всем, что они придумывают. Система проектов MSBuild достаточно надежна , чтобы делать что угодно (если, как говорит

Кроме того, вы можете узнать что-то новое, и это всегда хорошо. : ухмыляясь:

@neoKushan Раньше я писал сценарии msbuild с нуля, он действительно намного мощнее, чем приправленный msbuild. Но это тоже было не очень хорошо, и я очень рад, что больше не занимаюсь этим. Я думаю, мы могли бы придумать что-нибудь получше, чем это.

@CodingGorilla На самом деле моя главная

Я предложил сделать работу самостоятельно, чтобы поддержка project.json работала бок о бок с xproj. Тот, кто больше всего заботится, делает работу, верно?

И в этом собственно суть. Позволит ли мне команда сделать этот вклад? И если нет, то почему? В конце концов, это OSS, не так ли?

Затем, если вам нравится MSBuild и вы хотите его мощь, используйте xproj.

И если вам нравится инструментарий, созданный для ядра ASP.NET, вы продолжаете его использовать.

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

Да и работы в любом случае не должно быть и так много. Все, что мне нужно сделать, это преобразовать код, который они не рекомендуют, в другую команду.

В идеале я хотел бы иметь возможность использовать «dotnet build», посмотреть каталог и решить, какой из них использовать, исходя из того, какие файлы там есть. Но можно установить флаг опции при сборке или даже новую команду.

@sandorfr Я согласен, что написание полноценных файлов MSBuild, которые определяют ваш _подробный_ процесс сборки, - не что иное, как колоссальная боль, но, если я не ошибаюсь, мы говорим здесь не об этом - мы говорим о _простом_ проекте. структура.

Другими словами, MSBuild - огромная, мощная система, которая сопряжена с большой сложностью, но только если вы ее используете. VS по умолчанию бросил туда много дерьма, которое вам не нужно, и, глядя на xproj, становится ясно, что MSBuild это тоже действительно не нужно. Если команда Donet сосредоточится на минимизации того, что требуется в csproj, он должен быть относительно минимальным и понятным для большинства людей. Единственные, кто должен пострадать от «адского слияния», - это те, кому нужна эта дополнительная функциональность (которые, как я подозреваю, являются движущими силами этого изменения, пусть даже с ног на голову).

По-прежнему ничто не мешает вам использовать выбранную вами систему сборки, будь то CAKE, TFS Team Services или что-то еще.

Опять же, это оговаривается, что команда делает это «правильно».

VS - не лучший пример, и я думаю, что опыт, который дает вам VS, - это то, что многие люди действительно ненавидят в системе проектов MSBuild.

@neoKushan Вот как я отношусь к TFS Build и Xaml. Xaml до смешного хорош (и ему все равно нравится видеть, что он используется в качестве возможного формата для «скриптов» MSBuild), но его использование в TFS Build дало ему плохую репутацию.

Я не считаю продуктивным использовать эту проблему с github в качестве окна чата. Я хотел сохранить уведомления по электронной почте для этой темы на случай, если кто-то из MS ответит, но количество писем стало слишком раздражающим.

Система проектов MSBuild достаточно надежна, чтобы делать что угодно

Это часть проблемы и то, что затрудняет понимание того, что происходит в файле csproj при его чтении, что делает его плохим выбором для формата файла проекта (не путать с форматом файла определения сборки)

(Изменить: добавлено)

По-прежнему ничто не мешает вам использовать выбранную вами систему сборки, будь то CAKE, TFS Team Services или что-то еще.

К сожалению, это означает, что мы застряли, пытаясь внедрить нашу систему сборки в MSBuild, если мы хотим, чтобы VS мог разговаривать с ней (и работал правильно, когда есть и управляемый, и собственный код, и мы хотим отлаживать). Вот почему, на самом деле, я считаю, что это _функция_ - отделить файл проекта от файла сборки.

Ха-ха, да @ cwe1ss

Могу я предложить всем нам присоединиться к следующему выступлению сообщества в среду? Я подозреваю, что в основном речь пойдет о выпуске RC2 на день или два раньше (можно надеяться!), Но это даст нам всем шанс задать им необходимые вопросы и провести хорошее откровенное обсуждение с живой аудиторией. которые действительно могут дать ответы.

Могу я предложить всем нам присоединиться к следующему выступлению сообщества в среду?

Только если @shederman представляет. Я хочу видеть, как он в реальном времени разбивает разработчиков и их идеи. Как событие WWE PPV!

Я думаю, что преимущество project.json перед [projectName] .csproj не в формате. Речь идет об отсутствии обратной совместимости со всем старым. Это позволило сделать это довольно просто. Предполагая, что Дамиан Эдвард и его команда могут достичь всех поставленных им целей, мне все равно, что XML против JSON против YML против ... Что важно для меня, так это простота и отсутствие необходимости видеть то, что есть для Windows, когда я нахожусь в Linux. .

@glennsills Я не думаю, что в файле проекта MSBuild есть что-то специфичное для _windows_, скорее оно специфично для самой MS Build или других типов проектов, которые вас просто не волнуют. На самом деле нет необходимости иметь кучу пустых элементов только для того, чтобы MSBuild был доволен. Я надеюсь, что команда планирует убрать из этого как можно больше, но посмотрим.

@ Mike-EEE Только если @shederman представляет. Я хочу видеть, как он в реальном времени разбивает разработчиков и их идеи. Как событие WWE PPV!

Я постараюсь это сделать. Но предупреждаю, что говорю медленнее, чем печатаю, так что не надейтесь 😄

image

Итак, рискуя открыть банку с червями, учитывая https://github.com/dotnet/roslyn-project-system/issues/40, как люди будут относиться к действительно урезанному файлу csproj, который содержит только (По умолчанию ) самое необходимое для проекта?

(Пожалуйста, не превращайте это в тираду «Я ненавижу XML!»).

Как насчет тирады «Я ненавижу MSBuild»?

@shederman

Что, если мы заставим MSBuild принимать файлы JSON? : смеясь: (Не удержался)

@shederman : Трудно серьезно относиться к любой тираде, и я бы предпочел, чтобы Microsoft серьезно отнеслась к этому _обсуждению_.

Таким образом, через 5 лет вы будете программировать Swift, Java (!!), Node.JS или Elixir. ;)

В наши дни в .NET projects / Solutions / все остальное есть две дрянные технологии. Файлы Nuget и .csproj. Если вы работаете в команде 5+, используя Git (и например, GitFlow), это полный кошмар. «О, черт, если забыли включить файл в .csproj» становится утомительным. Инструменты должны это исправить, инструменты также должны предупреждать меня о конфликтующих версиях DLL, инструменты должны помочь мне со слиянием.

Отрежь дерьмо. Project.json сначала показался симпатичным, но потом начались политики и переживания.

Команда MS должна называть это бета-версией, а не RC.
Похоже, я не могу доверять, даже когда будет выпущена RTM, на случай, если MS Team решит выпустить RTM2, которая снова все сломала.
Я не пессимист, но движение вокруг .NET Core очень странное.

@neoKushan Я постараюсь вести себя

Я не согласен с условиями обсуждения, когда я должен отказаться от занимаемых мной позиций, чтобы войти в обсуждение. Я все время слышу, как те из нас, кто поддерживает project.json, должны принять в основном именно то, что решила MS, возможно, с небольшими изменениями или двумя.

Я не понимаю, как это следует. Мне просто нужна обещанная и обязательная система сборки. Если MS не желает поддерживать и продолжать это, я предложил.

Так в чем проблема? Я не прошу MS отказаться от своих планов, я не прошу добавить работу. Я просто прошу их позволить мне выполнить обещания, которые они в одностороннем порядке нарушили.

Вряд ли революционный запрос.

Мои 2 цента:

Я считаю, что это изменение обсуждают два типа людей:

разработчики, которые используют VS и .NET для создания различных проектов и должны поддерживать эти проекты в течение длительного времени
разработчики, которые не имеют такого багажа и хотят новую, чистую и модную кроссплатформенную платформу ASP.NET Core.
Лично я отношусь к первой категории, поэтому я хочу, чтобы новое ядро ​​ASP.NET было максимально совместимо с другими типами проектов VS, а переход на «старое» решение csproj / msbuild для меня - это победа (+ my команда и, вероятно, многие другие разработчики). Таким образом переход будет более плавным и четким. Может, люди из второй категории со мной не согласятся (или им все равно).

Единственная серьезная проблема, которую я сейчас вижу, - это то, как пакеты NuGet определяются и ссылаются на них. Больно поддерживать файлы packages.config и csproj (как @ cwe1ss, предложенное в # 1433 (комментарий)). Кстати, это был один из самых конструктивных комментариев в этой теме ...

Что касается священной войны XML / JSON ... ИМХО, XML лучше для ручного редактирования, чем JSON. XML поддерживает комментарии и дает больше контекстной информации, когда вы просматриваете его. JSON лучше подходит для данных, а не для файлов конфигурации. Слияние одинаково хорошо и плохо для обоих форматов, оно зависит исключительно от контента. Если бы ссылки на проекты были отделены от текущих файлов csproj, слияние также стало бы намного проще ...

Я также вписываюсь в первую категорию (разработчики, которые разрабатывают несколько проектов / типов и нуждаются в их поддержке в течение длительного времени). У моего работодателя есть миллионы строк кода проектов в формате csproj, и у нас также есть новые продукты, работающие в ветвях разработки ASP.NET RC1 и RC2. Честное предупреждение, мы также расширяем возможности использования MSBuild с настраиваемыми сборками задач MSBuild и т. Д.

Интеграция между ними в реальном мире оказалась неудачной (по нескольким причинам), особенно с учетом таких вещей, как создание оберток, повторное создание оберток при изменении обернутых зависимостей, как это выглядит в системе управления версиями (мы внутренне поддерживаем и используем как Git, так и TFVC). ), как проекты ссылаются друг на друга в решении во время разработки в VS по сравнению с тем, как они втягиваются во время сборки / развертывания. Система никогда не казалась правильной. Не имело смысла иметь два отдельных проекта, каждый с файлами .cs, но эти два типа проектов не могли хорошо сочетаться.

В связи с этим я полностью понимаю, почему так важно поддерживать приложения и код, которые были написаны до этого момента. Я не думаю, что сейчас подходящее время для внесения изменений такого типа, когда происходят все остальные изменения - кажется, что слишком много всего происходит одновременно.

Может быть, возможное будущее решение состоит в том, чтобы мы, взяв пример с других людей, подумали о выпусках LTS или о чем-то подобном? Это гораздо более обширный разговор, но затем можно было бы ввести некоторые функции, такие как замена проектной системы, и дать людям время осваивать ее.

Другое возможное решение - это более гибкая система сборки, но это более долгосрочное решение, которое не помогает текущему разговору. В принципе, разрешите либо /, либо / сторонний.

Что касается зависимостей проекта, у нас уже есть множество файлов packages.config, переносить их в файл packages.json / nuget.json не составляет большого труда. У меня больше проблем с несогласованными перенаправлениями привязки сборки, чем с форматом хранения зависимостей.

@shederman Вы очень хорошо высказали свое мнение о MSBuild, но то, что вы не внесли ясности, - это ваша реальная _ проблема_ с MSBuild. Это то, что меня так расстраивает, я просто хочу знать, с какими проблемами вы столкнулись при использовании MSBuild, потому что я искренне считаю, что их можно решить.

Хорошо, значит, вам не нравится XML, хорошо - в споре между JSON и XML нет ничего нового, и мы никогда не решим это здесь. Однако это не может быть _ единственной_ причиной, по которой вы так ненавидите MSBuild. С какими настоящими проблемами вы столкнулись?

Причина, по которой я спрашиваю - и причина, по которой я все время спрашиваю, заключается в том, что это именно те проблемы, которые Microsoft хочет исправить, и если мы не проясним, в чем заключаются проблемы, они не будут исправлены. Многие вещи, которые мы ненавидели в MSBuild, уже исправлены, о чем мы знаем:

  1. Листинг каждого файла в проекте - удаляемый / исправляемый (на самом деле проблема VS)
  2. Merge hell - Исправлено 1. в большинстве случаев.
  3. Излишняя сложность / многословие - надеюсь, решение будет решено https://github.com/dotnet/roslyn-project-system/issues/40
  4. Трудно редактировать вручную - опять же, исправлено 1. и 3.

Что осталось? Давайте на самом деле обсудим проблемы с MSBuild и посмотрим, есть ли решение, которое не предполагает разветвления всего или отказа от десятков тысяч сложных, критически важных для бизнеса проектов. Это обсуждение, которое я _ хочу_ вести.

Мои 2 цента на это:
Почему, черт возьми, происходят такие изменения прямо сейчас? Согласно дорожной карте до финального релиза остался всего 1 месяц.
Когда я впервые посмотрел на это, я подумал, что это шутка. Но, к сожалению, это не так.
Это большая пощечина прямо в лицо сообществу. Такое решение должно обсуждаться ДО того, как оно будет принято, а не после.

@laskoviymishka (и некоторые другие), как было отмечено здесь @neoKushan , это изменение _не_ сейчас происходит, это будет изменение после RTM (даже RTM будет поэтапно). Так что все разговоры о том, «почему изменения в последнюю минуту» - это немного ошибочный аргумент, пришло время посмотреть, как все будет развиваться.

@laskoviymishka Изменения не происходят до RTM.

RTM по-прежнему будет использовать project.json так, как он используется сегодня (я считаю, что схема меняется для RC2, но это все равно происходило). Переход на «новый» csproj запланирован после RTM, и это будет происходить постепенно. В RTM ничего не меняется (кроме переименования xproj).

@CodingGorilla - это RC2, который через месяц

@neoKushan, если это произойдет после RTM, почему бы не рассказать об этом

ИМХО этот переход от project.json к project.csproj следует обсудить, прежде чем он будет принят. Сейчас это не лучшее решение, по крайней мере, для меня.

@laskoviymishka Из сообщества : (выделено мной)

В RC2 / Preview 1 изменений не будет . В RTM / Preview 2 _это единственное изменение, которое вы увидите, будут ли файлы xproj переименованы Visual Studio в csproj_. С этого момента project.json будет жить рядом с csproj. Затем группа приступит к переносу функций из project.json в файл csproj. Возможно, останется файл project.json, содержащий все ссылки на пакеты для NuGet, и он будет переименован в nuget.json. Команда уже протестировала некоторую работу, которая показывает, что вам не нужно будет перечислять все файлы в файле проекта, что является одним из ключевых преимуществ модели project.json.

Таким образом, это в основном изменение инструментария, и в очень краткосрочной перспективе (т.е. RTM +) файл project.json все еще будет там и будет работать так же, как и сейчас. Я думаю, что хорошая новость по этому поводу заключается в том, что у сообщества еще есть время повлиять на это, если мы сможем сохранить вежливость и конструктивность.

@laskoviymishka Ну, я действительно не хочу говорить от лица Microsoft, я не знаю, каков их окончательный план, но я не думаю, что они действительно знают. Многие люди говорят, что коврик был вырван из-под них, и Microsoft следовало проконсультироваться с нами, прежде чем принять это решение, но на самом деле ничего не изменилось, и ничего не изменится в течение нескольких месяцев - плюс, когда изменение действительно произойдет, оно будет постепенное изменение и, надеюсь, тот инструмент, который более или менее подойдет вам.

Microsoft или, по крайней мере, команда asp.net запросили отзывы по этому поводу, и, без сомнения, они читают эти темы, но, возможно, нам не хватает окончательного бюллетеня или сообщения от Microsoft, в котором говорится: «Если вы хотите обсудить это, сделай это _здесь_ ". Однако я действительно думаю, что переход происходит намного раньше, чем думают люди. Пока что единственное, что они знают наверняка, - это переименовывают xproj в csproj.

Я лично считаю, что, хотя это немного дерьмовое изменение, я понимаю их причины, по которым они это делают. У меня нет лучшего ответа, поэтому я считаю, что если нам приходится иметь дело с проектами в стиле csproj, то мы можем также воспользоваться этим периодом, чтобы представить лучший _kind_ csproj, который мы можем. Это не будет project.json, но если мы сможем получить лучшее из обоих миров, то в долгосрочной перспективе нам всем станет лучше. Не все согласны, и это нормально.

@neoKushan, это хороший

@CodingGorilla: ну, в финальной версии все еще есть изменения, которые ломаются. Основная проблема таких изменений заключается в том, что основной команде приходится тратить много времени впустую. Скорее всего, это проблема менеджеров. Давайте потратим много времени на то, чтобы просто заменить одно работающее на другое, возможно, работающее. Без уважительной причины.

@neoKushan

Давайте собственно обсудим проблемы с MSBuild

Мне сложно найти достаточно информации, чтобы составить мнение. Было внесено множество изменений, которые _представлялись_ включенными в project.json и удалением файлов .csproj. Я не хочу, чтобы эти улучшения исчезли, но я не знаю, как переход на «новую и улучшенную» сборку msbuild изменит мой рабочий процесс:

  • В настоящее время мы используем gulp для каждой задачи сборки. Это изменится? Мой gulpfile просто запускается в dnu или dotnet-cli, чтобы фактически превратить коллекцию файлов .cs в сборку. Я могу это оставить, правда?
  • Будет ли VS продолжать поддерживать проводник задач и триггеры afterbuild / prebuild / etc для моих задач gulp, чтобы пользователи VS могли запускать F5? Или мне нужно, чтобы msbuild запускал gulp, что означает, что все мои задачи gulp требуют определения задач оболочки msbuild? (ой)
  • Есть ли msbuild в отдельной установке? Будет ли он версироваться отдельно от dotnet cli или от среды выполнения? Как это изменить минимум, который должен быть доступен на моем сервере сборки CI? Минимум для установки в среде разработки?
  • Если я использую текстовый редактор для добавления зависимостей nuget или файлов .cs, какие дополнительные шаги мне теперь нужно добавить, если они есть?
  • Когда я просматриваю набор изменений, в который пользователь VS добавил зависимость nuget и файл .cs, будут ли изменения csproj простыми и удобочитаемыми? (Для сравнения, с .net 4.6 и VS2015, я считаю, что изменения в csproj _не_ легко читаются человеком.)

Я хотел бы, чтобы люди, которые вносят это изменение, пытались найти сценарии, которые им необходимо рассмотреть (например, мой!), И обсудить их. Я надеюсь, что фраза типа «эй, мы перемещаем ваш сыр без каких-либо обсуждений» не станет СОП .net core.

этот инструмент более или менее подойдет вам

И это главная проблема. Чем меньше инструментов _required_, тем лучше. В настоящее время я могу использовать текстовый редактор и командную строку, не чувствуя, что плыву против течения. Надеюсь, это не изменится. В стране .net46 мне нужно отредактировать гигантский и подробный XML-файл, если я не хочу использовать VS, а смешивание пользователей VS с пользователями без VS в одном проекте - кошмар.

"Добро пожаловать в RTM. Это напоминание о том, что ваш файл проекта когда-нибудь изменится в ближайшем будущем. Мы уже решили это. Причины, но в основном это то, что нам нравятся углы больше, чем фигурные, и инструменты для сборки, да, сборка Мы не определили окончательную схему (но она будет основана на xml, см. выше), и имя файла определенно будет заканчиваться на .csproj, чтобы внести максимальную путаницу в любой устаревший инструментарий. Agile. (ps если вы продавец инструментов:: o) "

@Oceanswave красивый пример того, как не стоит заниматься разработкой программного обеспечения

@neoKushan

но то, что вы не разъяснили, - это ваша реальная проблема с MSBuild

Может, вам стоит прочитать мой предыдущий ответ на этот же самый вопрос от вас? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

За эти годы я потратил сотни часов на исправление, разработку и отладку файлов MSBuild. Я сделал Team Builds, я сделал огромные конвейеры сборки и развертывания. Я час за часом изучал подробные журналы, пытаясь понять, какого черта происходит какая-то странная ситуация. Я много лет платил за эту технологию и лично не хочу иметь с ней ничего общего. project.json был глотком свежего воздуха. После многих лет страданий с MSBuild у нас наконец сложилось впечатление, что MS это поняла, что изменение необходимо и оно применяется.

И это было великолепно. Простые сборки, простые правки, быстрые и понятные результаты. Это смыло память о тех часах, которые ругались на скрипты MSBuild. Казалось, что мы наконец-то отделились от трупа прошлого. Но нет, теперь мы прикованы к трупу, который так ненавидим, несмотря на обещание, что этого не произойдет.

Без обсуждения, без обзора, вообще без какого-либо участия.

Тот факт, что вы даже не подозреваете, насколько ненавидят MSBuild в некоторых кругах, просто доказывает, что вы не проработали это решение.

Я не верю, что MSBuild имеет какие-либо существенные функциональные ограничения в качестве системы сборки. Он невероятно мощный, и в этом смысле его главная слабость. Это сложно, потому что ему приходится обрабатывать очень много сценариев. Для простого сценария «восстановление, сборка, тестирование, упаковка» это действительно огромный перебор.

В моих командах мы работаем с разработчиками C #. Они находятся под давлением, сжатыми сроками, высоким стрессом. Они не хотят ничего, что им мешает или задерживает.

MSBuild - это другой образ мышления, основной переход от императивного кодирования к контексту. Разработчики просто ненавидят это. Они находят это тупым и противоречащим интуиции. Они этого избегают. Единственный MSBuild, созданный в любой из команд, которые я сейчас курирую, - это инструмент created.

За последние 5 лет я не встречал ни одного разработчика C #, который был бы взволнован или наслаждается работой с MSBuild. Посмотрите некоторые комментарии на Github за последние несколько дней. Я ни в коем случае не одинок в своей неприязни к MSBuild. MSBuild уже десять лет воспринимается как жернов на шее .NET-разработчиков. Является ли такое восприятие несправедливым? Да, вполне возможно.

Но что с того? С моей точки зрения, как руководителя отдела разработки программного обеспечения, мне нужны инструменты, которые приносят желаемые результаты. Я не получаю таких результатов с MSBuild. Я получаю эти результаты от project.json + gulp.js + powershell.

_Can_ MSBuild получить мне эти результаты? Конечно, может, но только если разработчики поработают в MSBuild для достижения этих результатов. А они просто этого не делают. Когда мы их принуждаем , они это делают, а потом уже не поддерживают.

Я не могу полагаться на инструмент, который ненавидят разработчики. Это простая реальность. И учитывая, насколько мне нравилось не использовать его самому, я не могу их винить.

Давайте на самом деле обсудим проблемы с MSBuild и посмотрим, есть ли решение, которое не предполагает разветвления всего или отказа от десятков тысяч сложных, критически важных для бизнеса проектов.

Итак, что можно сделать?

Примерно 5 лет назад, если бы некоторые из обсуждаемых сейчас изменений были бы внесены, я думаю, восприятие было бы лучше. Но этого не произошло, и теперь это вызывает серьезные негативные мысли среди огромного числа разработчиков. Насколько я помню, некоторые из этих проблем были подняты тогда в MSBuild и отклонены. Так же, как текущие вопросы поднимаются и отвергаются.

Я не знаю, как это исправить, правда. Я думаю, что должны быть серьезные перерывы. Как сделать их, не сломав то, что там есть? Слишком мало, слишком поздно. Так что я не вижу пути вперед с MSBuild, ни для меня, ни для разработчиков, которые работают на меня, ни с моими партнерами, ни с командами, которые работают на них, а не с клиентами, с которыми мы консультируемся. Ни одна из этих аудиторий не хочет использовать MSBuild, они используют его в инструментах, потому что должны, и они постоянно клянутся в этом. По общему признанию, обычно во время слияния.

Итак, _now_ вы хотите улучшить слияние? 10 лет спустя. Ведь орудие ругательство во многих кругах?

По сути, вы используете инструмент, разработанный для Build Masters в конце 90-х, который фактически используется разработчиками после 2010 года. Инструмент, использующий вывод для своей логики, используемый разработчиками для императивной работы и императивных инструментов. Инструмент, который использует очень гибкий, но неочевидный способ установки свойств, используемый разработчиками, которые думают, что наборы свойств представляют собой простой оператор присваивания, и не понимают, зачем вам вообще нужно делать PropertyGroup и не делать этого. Мне наплевать, чтобы узнать.

Это обсуждение, которое я хочу провести.

Конечно, я понимаю. Тем не менее, обсуждение, которое я хочу провести, отличается: «дайте нам то, что вы нам обещали, или позвольте нам дать это самим себе, потому что нам не нравится ваша старая новая идея, и нам нравится то, что было обещано».

Могу я поделиться чем-нибудь грустным? Из моих деловых партнеров, которые имеют такой же опыт, как и я (точнее говоря), в то время я был самым сторонником MSBuild. Я действительно _использовал_ это. Я узнал это. Я построил большие трубопроводы. Но это было более 5 лет назад, и с тех пор под мостом ушло много воды.

Чувак, я часто киваю, читая комментарии и историю

Подумайте: расширения Visual Studio (.vsix). Никто не хочет трогать их из-за того, насколько они устаревшие / старые / разные по сравнению со всем остальным, что существует в наши дни. Что ж, у вас есть НЕКОТОРЫЕ разработчики, которые хотят этого, потому что они заплатили свои взносы, изучив его загадочную систему - точно так же, как MSBuild.

Я тоже, наверное, самый опытный из тех, кого я знаю профессионально, кто когда-либо имел дело с MSBuild. Большинство разработчиков не хотят тратить время на его изучение (потому что вы определенно делаете это). Это почти как если бы это был отдельный язык.

Если бы он был «больше похож на .NET» (и имел бы лучшую интеграцию с VS), то я думаю, мы все согласились бы, что это был бы лучший продукт для работы и привлекательное предложение для рассмотрения.

@ Mike-EEE & @shederman По @shederman , я даже в основном согласен с его аргументами (я согласен с тем, что системы сборки и проектирования представляют собой странную смесь проблем).

Опять же, у меня нет лошади в этой гонке, я не возражаю, какой бы путь они ни выбрали. Мне просто очень нравится получать одобрительные отзывы и слышать, как я говорю (со стороной настоящего интеллектуального интереса в разговоре: смеется :)

Мне просто очень нравится получать одобрительные отзывы и слышать, как я говорю (со стороной настоящего интеллектуального интереса в разговоре: смеется :)

Рад помочь! :улыбка:

Но не подлежит ли ремонту? Это можно исправить?

На самом деле, все зависит от того, кого вы спросите. Поднять проблемы в их репо, как предлагает

@PhilipRieck Вы задаете действительно отличные вопросы! К сожалению, у меня нет окончательных ответов на все из них, но давайте посмотрим:

В настоящее время мы используем gulp для каждой задачи сборки. Это изменится? Мой gulpfile просто запускается в dnu или dotnet-cli, чтобы фактически превратить коллекцию файлов .cs в сборку. Я могу это оставить, правда?

Я не _ думаю_, что это изменится, я на 95% уверен, что то, о чем мы здесь говорим, влияет только на _definition_ проекта, а не на то, как проект фактически построен (по крайней мере, помимо вызова dotnet build). Интерфейс командной строки dotnet может в какой-то момент вызвать MSbuild, но к этому моменту это уже скрытая вещь.

Есть ли msbuild в отдельной установке? Будет ли он версироваться отдельно от dotnet cli или от среды выполнения? Как это изменить минимум, который должен быть доступен на моем сервере сборки CI? Минимум для установки в среде разработки?

У меня нет окончательного ответа на этот вопрос, но я бы мог представить себе, что MSBuild входит в состав интерфейса командной строки dotnet как полностью отдельная установка, даже если у вас уже установлен MSBuild (скажем, с VS). Однако с моей стороны это чистое предположение. Я знаю, что огромная цель всего этого проекта ".net всюду" состоит в том, чтобы минимизировать суету, чтобы заставить людей развиваться. Буквально должно быть apt-get dotnet-cli (или что-то еще), dotnet new, dotnet build. Вам никогда не придется вызывать MSBuild для сборки проекта, это задача dotnet-cli.

Если я использую текстовый редактор для добавления зависимостей nuget или файлов .cs, какие дополнительные шаги мне теперь нужно добавить, если они есть?

Для файлов .cs определенно ничего другого, как и сегодня - единственное, в чем они очень четко заявили, это то, что дни указания каждого файла .cs в вашем проекте уже позади (хотя, по-видимому, вы все еще можете сделать это, если хотите , глядя на тебя @ Mike-EEE). Что касается зависимостей, то, конечно же, в краткосрочной перспективе (в краткосрочной перспективе - месяцы) они останутся в project.json и будут работать точно так же, как и раньше. Есть шанс, что project.json превратится в nuget.json, и поэтому, кроме изменения имени, ничего не изменится, но есть и другие возможности для этого, и это, кажется, одна из главных вещей, в которых Microsoft очень не уверена - позвольте своему голосу быть услышанным о ваших предпочтениях по этому поводу.
(Мое личное предпочтение - иметь возможность делать что-то вроде.nuget.json но это только меня плевать).

Когда я просматриваю набор изменений, в который пользователь VS добавил зависимость nuget и файл .cs, будут ли изменения csproj простыми и удобочитаемыми? (Для сравнения, с .net 4.6 и VS2015, я считаю, что изменения в csproj не легко читаются человеком.)

Для файла .cs csproj вообще не должен меняться. Для зависимостей nuget - хороший вопрос, опять же, это несколько в воздухе. На самом деле это не должно вызывать изменения csproj, но на данный момент решающим фактором является то, должен ли nuget жить в nuget.json или должен ли csproj иметь этот материал - и если они разделены, насколько сложно будет загонять два?

И это главная проблема. Чем меньше потребуется инструментов, тем лучше. В настоящее время я могу использовать текстовый редактор и командную строку, не чувствуя, что плыву против течения. Надеюсь, это не изменится. В стране .net46 мне нужно отредактировать гигантский и подробный XML-файл, если я не хочу использовать VS, а смешивание пользователей VS с пользователями без VS в одном проекте - кошмар.

Я полностью и полностью согласен с этим, но Microsoft слишком много вложила в свои кроссплатформенные усилия, чтобы внезапно сделать это кошмаром. Под «инструментами» я подозреваю, что это будет связано с CLI .net, а не с VS или чем-то в этом роде. Не забывайте, что окончательная «конечная игра» для ядра .net - это быть очень гибкой, очень быстро меняющейся платформой, но такой, которая не заставляет вас тратить время на обновление каждые пару недель. Я _ весьма уверен_, что если вы напишете приложение dotnet 1.0 в июне, оно все равно будет строиться и запускаться через несколько лет, но в новых версиях будет выполняться «обновление dotnet» или что-то в этом роде, когда вы будете готовы . Даже когда наступает RTM, проекты RC2 по-прежнему будут собирать и запускать биты RC2, пока вы действительно не войдете и не измените цель на RTM (я думаю, в global.json или где-то еще?).

: смеясь: Когда я читаю подобные темы, мне интересно, есть ли у Microsoft моменты сожаления. Я действительно уважаю и сочувствую парням, которые сделали и делают все возможное, чтобы вывернуть Microsoft наизнанку, с целью сделать для разработчиков прозрачную, открытую и ориентированную на сообщество гавань. Ребятам, стоящим за этой трансформацией, не все равно. Они хорошие ребята. Прямо сейчас они должны быть между камнем и наковальней; менее чем конструктивные настроения сообщества, плавающие вокруг (развлекая меня), не помогают их делу.

Я хотел бы отметить, что замена множества функций создания волшебных проектов, которые в настоящее время существуют в среде IDE, на приложение командной строки, выполняющее множество волшебных манипуляций csproj, - плохая идея. Необходимо сделать файл определения проекта как можно более простым. Самая приятная часть project.json - это то, что я могу его читать и понимать.

@shederman Ваша проблема с MSBuild заключается в том, что в большой сложной системе он большой и сложный ....

Я также работал с командой Строит , и я абсолютно ненавидел его (Pinging @ Mike-EEE becuse мы оба говорили о том, как ужасно это опыт), я получаю это , но то , что вы описываете , это совершенно разные сценарий. MSbuild _ может_ быть большим и сложным, и по умолчанию VS _ делает_ его большим и сложным, но это то, что меняется .

Новый файл csproj должен быть намного меньше, а это значит, что «Отладка» должна быть значительно упрощена. Нет (или немного) чуши. Вы по-прежнему можете использовать любую _build system_, какую захотите, черт возьми, вы можете вызвать файл .bat, который просто вызывает "dotnet build" для * .csproj, и вы получите желаемый результат, как сегодня. Пусть dotnet cli работает с MSbuild, и вам даже не придется его трогать.

@neoKushan нет, спасибо.

Я хочу то, что было обещано, а не помаду на том, от чего нам сказали, что мы отказываемся.

И если вы не хотите дать нам то, что было обещано, просто позвольте нам дать это себе. Это все уже есть. Это должен быть просто случай сохранения рефакторинга. Я сделаю работу, как я уже сказал.

Я подозреваю, что причина номер 1, по которой нет желания оставлять это, заключается в осознании того, что это будет началом массового перехода от проектов MSBuild. Извините, но сохранение устаревшей технологии жизнеобеспечения не является одной из целей разработки .NET Core. Это?

Самая большая проблема со сборкой ms, кто это исправит и сколько времени это займет. Прямо сейчас у целых проектов сети САШ более 1000 открытых вопросов, некоторые из них действительно критические. Посмотрите SignalR.
До релиза остался месяц, и эта ошибка еще очень не близка к финальной стадии.

А теперь говорят, что сборку ms можно улучшить. Достаточно ли у MS ресурсов, чтобы справиться со всем этим устаревшим дерьмом 💩? Сможет ли сообщество справиться с этим? Я не очень верю в это.

@shederman

И если вы не хотите дать нам то, что было обещано, просто позвольте нам дать это себе.

Они не мешают вам НИЧЕГО делать. Идите вперед и раскройте его, вас ничто не останавливает. Если вы ждете разрешения Microsoft, значит, оно у вас уже есть, вы получили его, как только они открыли исходный код кода.

Это все уже есть. Это должен быть просто случай сохранения рефакторинга. Я сделаю работу, как я уже сказал.

Затем сделать его? Опять же, вам ничего не мешает.

Я подозреваю, что причина номер 1, по которой нет желания оставлять это, заключается в осознании того, что это будет началом массового перехода от проектов MSBuild.

Зачем им вообще это нужно? Какая разница для Microsoft, если вы используете MSbuild или что-то еще?

Настоящая причина номер 1 в том, что структура проекта ядра ASp.net действительно хороша только для ядра asp.net. Существуют сотни других типов проектов, которые просто не подходят для project.json. Не говоря уже о том, что у project.json есть свои проблемы, о которых мы, по-видимому, все забыли - отсутствие комментариев - моя любимая мозоль (и нет, предлагая какой-то другой формат до тех пор, пока его нет, XML не помогает).

Извините, но сохранение устаревшей технологии жизнеобеспечения не является одной из целей разработки .NET Core. Это?

Нет, но цель - помочь людям перенести их старые существующие проекты на ядро ​​.net. Кроме того, мы говорим о версии MSBuild с ядром .net, а не о полноценной настольной версии, разница есть .

Ваша единственная проблема в том, что они осмелились назвать это MSBuild. Если бы они придумали новый стиль проекта, который оказался XML, но назывался «CoreBuild» или что-то в этом роде, вы бы не стали мудрее, и все, что вам нужно было бы сказать, это «Я ненавижу XML!».

вы ждете разрешения Microsoft, значит, оно у вас уже есть

Не совсем так. Я не хочу его форкнуть , я хочу сохранить его в основном репо. Есть разница. Так что никому не нужно загружать совершенно новый .NET SDK. Я хочу, чтобы это было в инструментах, и для этого мне нужно их согласие.

Ваша единственная проблема в том, что они осмелились назвать это MSBuild

Нет, они хотят _использовать_ MSBuild. Небольшая, но важная разница. Переименуйте новую систему сборки project.json и назовите ее MSBuild, и я с радостью воспользуюсь ею.

вы бы не стали мудрее, и все, что вам нужно было бы сказать, это «Я ненавижу XML!»

Может быть 😄

Во всяком случае, по кругу.

Иду спать.

Я говорю, оставь это для стендапа. Никто никого не убеждает. Я почти уверен, что понимаю сторону сторонников MSBuild, но не согласен с этим. И я почти уверен, что сторона, выступающая за MSBuild, понимает сторону отказа от MSBuild, но не согласна с ней.

Все, что я говорю, это то, что у нас может быть и то, и другое. Никаких (или очень небольших) дополнительных усилий со стороны команды MS. Затем позвольте вариантам утонуть или проплыть в ярком свете фактического производственного использования.

Вопрос Per

Что осталось?

На самом деле я хочу сформулировать свой ответ, если можно, вокруг «принципов», которые я изложил выше, относительно того, что, по моему мнению, делает для хорошего, пригодного для использования файла проекта:

  • Он должен быть доступен для редактирования / чтения человеком

Принимая заявление @neoKushan выше как означающее, что оно будет рассмотрено - я предполагаю, что кто-то в MSFT сказал / написал это. С учетом вышесказанного, я хочу увидеть предложение на основе MSBuild, в котором эта проблема фактически решается в первую очередь, прежде чем «фиксировать» (как сообщество / фреймворк) в MSBuild.

Я предполагаю, что избавление от Guid ProjectType является одним из главных вопросов, которые необходимо решить?

Но я поддерживаю свое добавление выше: это жесткое (не подлежащее обсуждению) требование, чтобы для простых проектов (например, ASP.Net Hello World в Angular) я мог полностью создать его вручную в блокноте. Если мне нужно использовать Yeoman / VS / similar, мы не смогли предложить файл проекта, редактируемый человеком.

  • Это должно позволять комментарии

Уже работает, в MSBuild

  • Это должно быть декларативным

Изменение порядка первого уровня (прямые потомки) может изменить весь смысл проекта, часто трудными для отладки способами. Это особенно заметно, если вы случайно вынесли импорт .targets на первое место.

  • Он должен быть автономным

Это моя самая большая проблема с MSBuild. Статическое чтение файла не дает вам достаточно информации, чтобы действительно знать, что там происходит. От файлов .targets, которые поступают из путей, указанных в _environment variable_, и того факта, что переменные среды поддерживаются событиями, до условных выражений и импорта, вместе вы получаете то, что фактически является средой Turing Complete, за счет очень высокого уровня сложности. , и плохая инструментальная способность. Я утверждаю, что ужасная интеграция VS с MSBuild является следствием сложности создания инструментов на их основе.

Это похоже на проблему удобочитаемости / редактируемости человеком.

  • Он должен быть разработан так, чтобы уменьшить конфликты слияния / упростить слияние, если это возможно.

MSBuild технически поддерживает это в виде подстановочных знаков. Поддержка VS для подстановочных знаков хуже, чем ужасная. Это активно усложняет работу. Как указано выше, я готов согласиться с тем, что это будет исправлено, но это должен быть элемент в _proposal_ to _migrate_ (и это миграция, потому что все сообщения, до сих пор относящиеся к project.json) в MSBuild файлы проекта.

  • Он должен быть полностью документирован (с применением принципа самодостаточности документации).

Я считаю, что у MSBuild есть документация. Эта документация, особенно для VS _flavor_ из MSBuild, оставляет желать лучшего. Я часто недоумеваю, почему разные вещи находятся в группах, и VS «помощь» их перемещать не очень помогает.

Прекрасным примером является пакет Bond NuGet. Сколько людей знают, что если у вас нет папки BondInclude на диске (если на нее есть ссылка в csproj), сборка таинственным образом не сможет фактически сгенерировать какой-либо из типов Bond в результирующую сборку? (И без выброса ошибок). Затем создание пустой папки с таким именем и перезагрузка проекта исправят это.

(Да, я знаю, я собираюсь сообщить об этом)

  • Он должен быть независимым от инструментов

Скажем, я не хочу иметь ничего общего с MSBuild (скажем, потому, что я чувствую себя противоположным, не вдаваясь в подробности); Я просто хочу определить свой проект и загрузить пакеты через самородок. Почему я вынужден использовать именно эту систему сборки? Особенно, если все, что я хочу, - это определить проект?

Файл определения сборки не является форматом файла проекта. То, что VS удалось заставить его работать (в некоторой степени), не является хорошим основанием для продолжения использования его как такового. Мне нужен настоящий файл, который просто представляет сам проект и информацию об артефакте, который он генерирует (а не инструкции по его созданию). В этом случае не работает даже project.json, потому что он позволяет нам определять «команды». Почему они существуют? Просто определите, что это за тип вывода и где его можно найти.

Я прочитал всю эту ветку, и одна вещь, которая запомнилась мне в этом обсуждении project.json vs project.csproj - это то, что только одно из этих имен файлов содержит весь язык программирования. Я предпочитаю заниматься разработкой ASP.NET на F #. Возможно ли такое даже в ASP.NET Core? На данный момент я не имею ни малейшего представления, но чувствую, что это не так. Я даже не уверен, используют ли люди csproj как сокращение для csproj, fsproj, vbproj или они действительно имеют в виду только csproj .

Обновление: люди F # работают над поддержкой CoreCLR, но реального ETA пока нет. Я хочу сказать, что какая бы проектная система ни была выбрана сейчас, это повлияет на языки программирования, которые, похоже, сейчас даже не привлекают внимание людей. Насколько я предпочитаю JSON над XML, если project.json собирается заблокировать меня в C # (а порядок файлов при компиляции критически важен в F #), то я не за это.

А пока, похоже, для меня это снова FAKE и Paket ...

Я работаю с .NET с самого начала, и у меня никогда не было серьезных проблем с MSBuild. Основная причина этого в том, что я никогда не использовал его ни для чего другого, кроме компиляции готового решения.

И вот чего я не понимаю в этой неприязни к MSBuild. Никто не заставляет кого-либо использовать MSBuild для чего-либо, кроме компиляции решения. И я думаю, что возможность скомпилировать решение - довольно полезная функция, которой, кстати, еще даже нет в "dotnet cli" (вы должны вручную прокручивать проекты прямо сейчас - поправьте меня, если я ошибаюсь).

Ваша фактическая система сборки не нуждается в изменении. Если вы используете Nant, продолжайте использовать Nant. Если вы используете psake, продолжайте использовать psake. Если вы используете сценарий PowerShell, продолжайте его использовать. И т.д! Скорее всего, вызовом MSBuild нужно заменить только часть «dotnet build». (Возможно, даже это не понадобится, если dotnet build вызывает MSBuild)

Я бы сказал, что это делает MSBuild довольно несущественной деталью реализации. Вот каким я его видел последнее десятилетие, и таким я буду видеть его и дальше.

Но, конечно, как я уже сказал в начале этого потока, нам определенно нужны некоторые из _features_ project.json и Visual Studio для лучшего обращения с csproj - и я не понимаю, почему бы им этого не сделать. быть в состоянии доставить это.

@jtmueller Нет абсолютно никакой _технической_ причины, по которой вы не должны иметь возможность использовать F # (или VB.net, если вы так склонны). Я не удивлюсь, если переход на файлы проекта MSBuild частично поможет этому. DNX никогда не был очень доволен этим, но CoreCLR определенно поддерживает F #. Я не знаю, сможете ли вы использовать F # come RTM, но он определенно находится в стадии разработки.

@jtmueller project.json - это в значительной степени определение проекта с манифестом зависимостей и настраиваемыми командами. Там вообще ничего не привязано к конкретному языку.

Система сборки моей мечты (чтобы полностью заменить MSBuild) будет использовать Roslyn для определения задач и целей, что позволит вам использовать F # для определения процесса сборки (или C #, или VB.NET, все, что поддерживает Roslyn).

Конечно, этого пока никто не предлагает. Но возвращение нас в MSBuild почти наверняка закроет эту дверь на очень долгое время.

Приятно отдохнули и немного поговорили о том, что нужно сделать, чтобы «спасти» MSBuild. Я не верю, что мы можем или должны превратить MSBuild в совершенно иную систему сборки. Это основанная на логическом выводе система сборки, определяемая XML, и она работает для нее и для многих сценариев людей, особенно для некоторых из более сложных сценариев.

Но не у всех из нас есть преданные мастера сборки, которые могут спорить с MSBuild. Не всем нам нужна мощь, которую дает сложность MSBuild. Некоторые из тех, кому действительно нужна такая сложность, не хотят использовать MSBuild. В одной из моих команд, например, вся настраиваемая логика сборки выполняется на этапах до и после сборки, Exec, по сути, выполняет оболочку для Powershell. Не потому, что это невозможно сделать в MSBuild, это возможно, и в этом случае, вероятно, _должно_. Но потому что они не хотят делать это в MSBuild.

Шаг первый , безусловно, заключается в том, что нам нужно отделить определение проекта от системы сборки. Для меня это имеет огромный смысл. Мы можем обсудить разделение зависимостей вне определения проекта, но я не считаю, что это необходимо.

Шаг второй : нам нужна система сборки. Нам нужно обрабатывать как очень простые, так и очень сложные варианты использования. Но ни одно правило не говорит, что одна система сборки должна обрабатывать и то, и другое. На мой взгляд, наиболее разумно иметь простую и легкую систему сборки, которая в основном просто строит определение проекта. Это делает restore , build , test и pack .

Я думаю, мы также должны найти способ, чтобы он мог работать _без_ определения проекта вообще, используя структуру каталогов в качестве определения. Очевидно, такая ситуация будет означать, что он будет использовать стандартную структуру и зависимости по умолчанию. Может быть, возможно, а может и нет. Но мы можем взглянуть на каждый элемент в определении и спросить: «Можем ли мы сделать вывод о разумном значении по умолчанию для этого»?

Но хотя этого, вероятно, достаточно для 80% случаев использования, этого недостаточно для остальных 20%. Им нужно нечто большее. (предостережение: мнения о соотношении вариантов использования могут отличаться).

Третий шаг заключается в том, что мы разрешаем очень простую форму расширяемости этой системы сборки. Но мы говорим очень просто. По сути, он может запускать как базовую сборку, так и внешнюю систему сборки. Упомянутая внешняя система сборки может быть MSBuild, или сценариями, или какой-либо другой системой сборки.

Я счастлив, что новый процесс сборки может быть реализован в MSBuild, но я не верю, что что-то вроде (IMO) старого, сварливого и раздутого, как MSBuild, должно быть основой для всех сборок в будущем.

С такими вещами, как веб-фреймворки, мы видим, как команды MS отчаянно работают. Потому что у них конкуренция. Им приходится беспокоиться, например, о том, что Нэнси дышит им в шею. Легко переключиться на что-нибудь другое. И это делает MVC / WebAPI лучше для этого.

Когда MSBuild встроен во все инструменты .NET, становится сложно использовать что-либо еще. Где конкуренция? Эффект от этого можно увидеть на плате MSBuild Github. Просто просмотрите все Закрытые предложения. Единственная причина, по которой они сейчас говорят о внесении этих «похудающих» изменений, заключается в том, что они хотят, чтобы люди перешли с project.json на MSBuild.

Если бы MSBuild был встроен в .NET Core с самого начала, я полагаю, что мы бы не увидели ничего из того, что мы наблюдаем сейчас со стороны команды MSBuild. Но что произойдет, когда мы снова заперты? Как только конкуренция в принципе исключена? Что должно случиться? Что всегда происходит в сценариях без конкуренции и что происходило годами до сих пор: ровно столько улучшений, чтобы остановить массовые дезертирства, но ничего особенно интересного.

Меня спрашивали, как, по моему мнению, можно «спасти» MSBuild. Я считаю, что единственный выход - открыть его для реальной конкуренции и выбора. Принуждение к нему всех разработчиков, даже тех, кому не нужно ничего такого мощного (да, я действительно считаю, что это мощное средство), только вызовет еще большее недовольство против него.

Это не рецепт успеха любого фреймворка.

Пожалуйста , все, имейте в виду, что мы все хотим , чтобы добиться успеха .NET. Я _love_ .NET, я считаю C # одним из лучших языков программирования, и мне понравился его медленный переход на Scala - The Good Parts ™ 😉.
Я не верю, что мы начнем заново с .NET Core и сделаем это, приковав себя к одной из (ИМО) худших частей старого стиля .NET. Да, MSBuild, но нет, не прикован к нему.

Во что бы то ни стало, держите его, но не в центре системы.

Система сборки моей мечты (чтобы полностью заменить MSBuild) будет использовать Roslyn для определения задач и целей, что позволит вам использовать F # для определения процесса сборки (или C #, или VB.NET, все, что поддерживает Roslyn).

УААААААААААС !!! Кстати, о каком ... это подходящее место для разговора? У нас также есть репозитории Roslyn и MSBuild, и они, похоже, тоже должны быть задействованы. Я предполагаю, что мы пробуем использовать репозиторий MSBuild, но они (как вы упомянули) очень жесткие и негибкие. Я думаю, что присутствие здесь большего количества людей, подобных интересу, который вызвала эта ветка, может иметь большое значение для реформ.

Третий шаг заключается в том, что мы разрешаем очень простую форму расширяемости этой системы сборки.

Система / модель сборки на основе провайдера ?! ГЕНИЙ! Я одобряю это сообщение.

Кстати, если у вас есть желание и у вас есть доступ к вашей собственной системе сборки, я предлагаю назвать ее ... BERSERKER BUILD! Назван в честь "Berzerker @shederman" ... мой новый ник для тебя. :улыбка:

@ Mike-EEE Не волнуйтесь. Ни в коем случае я не предлагаю ничего столь же радикального, как все это _yet_.

На данный момент я думаю, что это должны быть только шаги один и два, с поддержкой MSBuild для третьего шага.

Но я думал, что к такой возможности мы двигались, когда получили project.json, отделяя проект от сборки, чтобы было легче менять поставщиков сборки. На мой взгляд, возвращение MSBuild в корневой каталог закрывает эти возможности. Или, по крайней мере, делает их менее привлекательными.

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

это подходящее место для этого разговора

Я так не думаю, нет. Кроме того, не думайте, что знаете, что сейчас подходящее время. Нам нужно закрыть эту проблему, прежде чем посмотреть, какие направления возможны.

BERSERKER BUILD! Назван в честь "Berzerker @shederman" ... мой новый ник для тебя. :улыбка:

Не знаю, как к этому относиться 😉

Не пытаюсь быть берсерком. Я просто не хочу двигаться назад, когда мы _двигались_ вперед.

Привет, ребята, может быть, вместо того, чтобы изобретать колесо ( nuget.json или как там оно будет называться), давайте воспользуемся существующим, управляемым сообществом решением, которое решает большинство проблем управления зависимостями - Paket .

  1. Имеет понятие транзитивных зависимостей.
  2. Хорошо интегрирован с MsBuild
  3. Он имеет удобочитаемый формат файла для определения зависимостей.
  4. У него очень хороший путь миграции с packages.config
  5. И многие другие функции (но, очевидно, эти 4 вещи являются наиболее важными для всех, поэтому я не буду упоминать такие вещи, как зависимости Git или лучшую стратегию разрешения пакетов)

@ Krzysztof-Cieslak помните, что самая большая причина, по которой Microsoft продвигает определения проектов MSbuild, заключается в том, чтобы облегчить миграцию тех, кто много вложил в MSBuild. В этом отношении Paket ничем не лучше project.json (или project.yaml, или project.cs, и т. Д.).

Сказав это, я все еще не вижу причин, по которым вы не можете использовать любую систему сборки, которую хотите. В конечном счете, «сборка dotnet» не изменится, независимо от того, в каком формате окажется ваше определение проекта, сборка dotnet все равно будет генерировать ваши выходные данные.

@neoKushan Да, но будет ли "dotnet build" требовать файл MSBuild, даже если мы не используем MSBuild? Будет ли он строиться, если файла MSBuild нет вообще? Или он будет транслироваться в MSBuild, который затем будет обрабатывать любую другую используемую систему сборки?

@shederman Несомненно, «dotnet build» будет использовать MSBuild в фоновом режиме для создания проектов, но вопрос о том, действительно ли мы видим это или нет, очень неясно. В настоящее время вам нужен project.json для правильной сборки ваших проектов, если не для ссылок, то для других важных данных (например, целевых фреймворков). В конечном итоге часть (или даже все) из этого будет перенесена в файл csproj, поэтому можно предположить, что вам понадобится этот .csproj для работы сборки dotnet, независимо от того, что она в конечном итоге использует в фоновом режиме. Однако еще неизвестно, насколько сильно это повлияет на вас.

Как я уже сказал, я счастлив до тех пор, пока мне разрешено выполнять эту работу, и держать на месте облегченную сборку, которая вообще не требует никакого MSBuild. Вы, ребята, можете построить свой самореферентный конвейер «MSBuild везде» в любом тупике.

Но если это сработает, тогда csproj нужно будет включить project.json, как предлагал RichiCoder.

Таким образом, «сборка ядра» и «MSBuild» могут работать бок о бок, или сборка ядра может работать без MSBuild. И, очевидно, если вы не импортируете project.json, вы также можете определить свойства своего проекта в csproj.

На самом деле, довольно простое изменение. В первую очередь нам нужно:

  • Сохраните существующий код сборки dotnet и пусть он запускается в определенных (которые предстоит определить) обстоятельствах.
  • В других он запускает MSBuild в соответствии с планами основных команд DotNet.
  • Может ли VS читать project.json или MSBuild для свойств проекта.
  • Добавить возможность импорта project.json в MSBuild

Это довольно небольшой объем работы, и он позволяет Microsoft продолжать идти по пути «MSBuild forever», выполняет обещания, данные сообществу .NET Core, и позволяет тем из нас, кто хочет отказаться от MSBuild, сделать это.

Примечательно, что никто из участников asp.net ничего здесь не сказал.

Между тем, я перечитал некоторые заметки из Standup сообщества ASP.NET - 10 мая 2016 г. , и они говорят о «новой» системе MSBuild, но не говорят, что это такое, за исключением того, что для этого не потребуется Visual Studio для редактирования. Отстойно, что он не был разработан в asp.net и должен быть добавлен (сейчас) так поздно в игре ... когда дизайн не включал это с самого начала. На самом деле, project.json должен просто включать элемент {"BuildSystem": "MSBuild"}, если вы хотите / должны пойти по этому пути. Я также удивляюсь, почему MS не может (известные последние слова) «просто» разрешить комментарии в файлах json с помощью инструментария.

@rhires Насколько я понимаю, «новая» система MSBuild - это несколько настроек, чтобы сделать XML немного легче, например включение всех файлов cs в сборку и выгрузка зависимостей в файл nuget.json. Никаких существенных изменений в дизайне, архитектуре или использовании MSBuild.

Мне нравится ваша идея project.json. Просто проходил изменения RC2, и они добавили "testrunner", так что нет причин, по которым это нельзя было бы сделать. _BUT_, похоже, их сердца полностью настроены на полное удаление project.json и возвращение в мир, ориентированный на MSBuild.

почему MS не может (известные последние слова) "просто" разрешить комментарии в файлах json с помощью инструментов

Нет причин, по которым они не могли этого сделать. JSON.Net, библиотека, которую они используют, поддерживает комментарии.

На самом деле, project.json должен просто включать элемент {"BuildSystem": "MSBuild"}, если вы хотите / должны пойти по этому пути.

Зачем мне нужно, чтобы мой проект диктовал свою собственную систему сборки? Конечно, система сборки строит проект, а не наоборот?

@neoKushan :

помните, что основная причина, по которой Microsoft продвигает определения проектов MSbuild, заключается в том, чтобы облегчить миграцию тех, кто много вложил в MSBuild. В этом отношении Paket ничем не лучше project.json (или project.yaml, или project.cs, и т. Д.).

Paket - это не новая система сборки, это менеджер зависимостей, который на 100% совместим с MsBuild. Это просто решает проблему packages.config .

@ Krzysztof-Cieslak Я никогда не утверждал, что это система сборки, и управление зависимостями на самом деле не является серьезной проблемой с ядром .net (насколько мне известно, по крайней мере). Ядро .net не использует packages.config оно использует project.json .

Если бы .Net Core по-прежнему планировалось использовать project.json у нас не было бы этого обсуждения 100 сообщений. ;) Все, что я говорю, это то, что во многих местах предлагается решение использовать "nuget.json" для обработки зависимостей заново изобретать колесо, поскольку у нас есть продукт, который делает то же самое.

@shederman

«Окончательные результаты опроса: 100 ответов для 9 миллионов разработчиков .NET, это ± 10% при 95% достоверности».

Да, и вопрос на конференции об игрушках для кошек, которые являются предпочтительным домашним животным, собаке или кошке, может дать вам аналогичные результаты.

@darrelmiller

«Я думаю, что важно проводить различие между MSBuild и тем, как Visual Studio в настоящее время использует MSBuild. Я годами вручную редактировал файлы MSBuild и использую их для всех своих проектов. Например, https://github.com/tavis- программное обеспечение / Tavis.home / blob / master / build / Build.proj "

Должны ли мы обсудить конкретные файлы сборки VS поверх файлов проекта, где msbuild не работает из командной строки?

@gregoryyoung Мы должны. Раньше я делал файлы сборки, которые зависят от devenv, но не видел файлов, которые не запускались бы из командной строки. Есть примеры?

@gregoryyoung

Да, и вопрос на конференции об игрушках для кошек, которые являются предпочтительным домашним животным, собаке или кошке, может дать вам аналогичные результаты.

Это интересная аналогия. Кроме...

Я разместил ссылку в Твиттере людей, которые _поддержали_ переход на MSBuild. Так что на самом деле это совсем не похоже на вашу аналогию.

И мне нравятся постоянные оскорбления о том, что опрос был предвзятым, проводился не на том форуме или ненаучен. Но вопросы не были ведущими, на ответы был широкий диапазон ответов, и опрос, да, был выбранной аудиторией, но широкой аудиторией, которая, по крайней мере теоретически, должна отклонить с моей точки зрения.

У меня также сложилось впечатление, а в некоторых случаях подтверждение, что люди, выдвигающие эти обвинения, только что немного погуглили об опросах. Я лично разработал протокол исследования уровня магистра для исследования здоровья, и хотя я не буду утверждать, что опрос идеален, он определенно не так ошибочен, как утверждают сотрудники Microsoft.

Это, безусловно, статистически значимо, и это дает вам хорошее представление о том, где находится мнение. GitHub, gitter, Twitter и блоги в той или иной степени поддерживают это.

Об одном и том же говорит множество источников доказательств. Если вы хотите игнорировать мнение значительной части ваших пользователей, скажите об этом. Перестаньте пытаться отмахнуться от их возражений, как будто вы потеряете право высказывать свое мнение, если придерживаетесь «неправильного» мнения.

Или еще лучше, как я уже много раз говорил, создайте свой собственный опрос, который улучшит то, что, по вашему мнению, не так с моими.

Причина, по которой я провел опрос, заключается в том, что было совершенно ясно, что Microsoft не имела ни малейшего представления о том, о чем думают люди. Сейчас становится совершенно ясно, что они не заинтересованы в том, что думают люди.

Перестаньте вести себя нечестно по отношению к себе и своему сообществу и вступите в бой с оппозицией, а не отмахивайтесь от нее.

Перестаньте пытаться изменить факты и начните менять свое мнение, основываясь на фактах.

@shederman У меня нет впечатления, что команда Microsoft действительно ответила на эту тему (включая ваш опрос). Да, один парень из команды сказал, что не считает его таким заслуживающим доверия, как вы, но это все. Я думаю, что все еще есть надежда, что они в настоящее время говорят о массовом неприятии того пути, который они выбирают, и они обсуждают правильный курс, и они ответят нам, когда узнают больше.

Думаю, мы можем отдать должное этой команде;).

@gregoryyoung Извините,

@sandorfr

Я думаю, мы можем отдать должное этой команде

Я думал, что сможем, но мой опыт последних нескольких дней не укрепил эту надежду.

Я должен думать, что это вина не «команды», а кого-то более высокого уровня в организации, который принял это решение и навязывал его ... а затем «команда» должна принять это и сделать так, чтобы оно выглядело красиво. BTDT. Не смешно.

Вы все понимаете, что project.json в последнее время уже претерпел большие изменения , чтобы сделать его более совместимым с приложениями, отличными от ASP.NET Core? Если вы просто посмотрите на пример в этом сообщении с объявлением, он уже становится довольно раздутым из-за всей этой конфигурации сборки.

Переход от этого к «классическому» файлу csproj на самом деле не кажется мне таким уж трудным делом. И если сам csproj также немного эволюционирует в более гибком направлении, которое мы узнали из project.json, я действительно вижу, что «новый и улучшенный» csproj действительно хорошо работает. И я думаю, мы можем с уверенностью предположить, что эти недавние изменения в project.json не были последними в курсе, чтобы сделать его пригодным для _все_ видов .NET-проектов - я думаю, важно, чтобы мы не забывали, что там есть много других целей, кроме ASP.NET (Core).

И на самом деле не имеет большого значения, является ли формат файла JSON, XML или каким-либо другим. Да, одно может быть лучше другого по разным веским причинам, но, в конце концов, вы должны подумать о том, сколько времени вы действительно хотите потратить на файл проекта . Да, с проблемами, с которыми мы столкнулись с текущими форматами, мы потратили больше времени, чем хотелось бы, но в идеале, предполагая, что мы исправим эти причины, мы должны проводить невероятно маленькую часть нашего времени в этих файлах. И в то время вам действительно не нужно беспокоиться о том, в каком формате он находится. Особенно, если в конечном итоге все это осуществляется с помощью инструментов (включая полное завершение в редакторах).

Я чувствую, что когда люди думают о project.json, они в основном думают о ранних стадиях, которые в большей степени связаны

Итак, tl; dr: Да, мне очень нравится project.json, и я бы хотел, чтобы был способ сохранить его для ASP.NET Core (например, с помощью специальной задачи MSBuild). Но в то же время я полностью понимаю, почему это происходит сейчас, и думаю, что на самом деле они поступают неплохо. Конечно, время немного странное, но, учитывая, что изменение не произойдет параллельно с выпуском ASP.NET Core и .NET Core, я не думаю, что время является актуальной проблемой (при условии, что переход позже будет плавным. ).

необходимость обмениваться исходными файлами между проектами

@darrelmiller Для меня это звучит пугающе, потому что, похоже, это означает, что список файлов в .csproj возвращается.

@lokitoth Предполагая, что csproj будет работать для файловых ссылок так же, как и более новый project.json, ничто не мешает вам использовать глобусы в целом и иметь отдельные ссылки на файлы вместе с ними.

@shederman Я не работник РС, а просто разумный человек. Если вы загуглите меня, я уверен, что вы поймете, что у меня есть долгосрочный интерес к платформе.

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

Слышать об этом изменении было неутешительно. project.json, автоматическое включение / добавление файлов и транзитивное восстановление были первыми вещами в ASP.NET Core, которые заставили меня сказать «о, как хорошо!» с начала.

Я понимаю, что не все это исчезнет (надеюсь?). Но возвращаться к файлу проекта XML - это плохо, потому что исторически это означало головную боль для людей. Я ненавижу открывать файл csproj для решения проблемы, потому что это стена из сложного для синтаксического анализа текста.

Всего два цента.

Глядя на изменения в сообщении @poke, похоже, что они в основном перевели csproj в json, что, честно говоря, тоже довольно неприятно.

Исходя из того факта, что они хотят поддерживать параметры Compile, Embed, CopyToOutput, Exclude, Shared Files и т. Д., Формат json в любом случае не будет работать лучше, чем XML. Я также подозреваю, что json не сработал бы также для тяжелой настройки скриптов сборки.

Я только надеюсь, что эта команда старается не добавлять еще один наполовину готовый раствор в производство, пока у них не будет времени найти способ сделать это хорошо.

@gregoryyoung то, что вы предоставили, бесполезно для любого разумного обсуждения

Здорово. Ладно, посмотрим, что я предоставил:

  • Я жаловался на переход на XML, как и многие другие
  • Я жаловался на переход на MSBuild, как и многие другие
  • Я попытался понять причины и доказательства этого решения, которые на самом деле не были представлены, кроме некоторых очень волнистых вещей.
  • Я попытался понять, что лежит в основе _мыслия_, лежащего в основе решения, которое _также_ на самом деле не было предоставлено
  • Я попросил сообщество высказать свое мнение, о чем MS вообще не позаботился.
  • Я попытался придумать альтернативы, которые позволят результаты, заявленные людьми, указывающими причины, но также позволят сообществу сохранить свой простой процесс сборки, который им нравится.
  • Я предложил выполнить необходимую работу, чтобы поддержать указанные альтернативы.

Могу я из интереса спросить, в чем безумие? Допросить чье-то мышление в наши дни не рационально? Или я что-то там оставил?

Я имею в виду, я злюсь , не поймите меня неправильно. Я потратил много работы, времени и денег на то, чтобы строить вокруг основного обещания фреймворка, который был оторван в последнюю минуту, что кажется опрометчивым и плохо продуманным ходом. Разве я не имею права сердиться?

PS. Ах, это ты Грег Янг. Уважать. Люблю свою работу. Я действительно.

@bzbetty Я полностью с вами согласен. Последнее, что я хотел бы увидеть, - это переосмысление MSBuild в project.json. Одна из самых больших проблем с MSBuild в его нынешней форме состоит в том, что он объединяет _проект_определение_ с _созданием_процесса_.

Таким образом, добавление процесса сборки в project.json приведет к той же ошибке, что и MSBuild / VS.

Определение проекта должно стоять отдельно от процесса сборки и использоваться в процессе сборки.

И тогда следует спросить: если ваш проект прост и ему просто нужно напрямую построить определение проекта, действительно ли вам нужна тяжелая, расширяемая, настраиваемая, гибкая и интуитивно понятная система сборки только для простой сборки?

Другими словами. Если бы у вас было такое простое определение проекта и очень простой инструмент сборки, который не мог бы делать ничего, кроме создания определения проекта, выбрали бы вы затем установку и использование MSBuild, NAnt или тому подобное?

Нет, наверное, не так ли? Я имею в виду, зачем излишне усложнять. Ключевой частью эффективной практики программной инженерии является простота.

Но как только вы столкнетесь со сценарием, с которым простой инструмент «построить определение» не сможет справиться? Конечно, тогда ты будешь.

Я предлагаю установить оба инструмента рядом, чтобы мы могли выбрать, какой из них лучше всего подходит для наших нужд. MS говорят: нет, вам когда-либо понадобится только сложный и нелогичный инструмент, но мы удалим самые вопиюще плохие функции.

Soapboax

Я просто хотел бы поделиться небольшим исследованием, которое я проводил. Я смотрел Twitter, Slack, Github, Gitter и Jabbr.

Я видел очень небольшую поддержку этого шага за пределами основной команды. Я имею в виду, что были, но не очень. Большинство людей очень расстроены переездом.

Меня также довольно встревожила тенденция многих сторонников MSBuild делать вывод, что их оппоненты дезинформированы или, что чаще всего, неквалифицированы. Этому соответствовала тенденция в лагере pro-project.json делать выводы о плохих мотивах (включая меня, mea culpa).

Я хотел бы спросить следующее:

  • Люди полагают, что люди, придерживающиеся мнения, отличного от их собственного, придерживаются их по уважительным причинам. Они не обмануты, некомпетентны, соучастники или сумасшедшие
  • Люди атакуют аргументы и доказательства, а не людей
  • Любые представленные доказательства не должны сразу отклоняться без веских причин.

Аргументы в пользу
Основные причины перехода на MSBuild, по моему мнению, следующие:

  • Поддержка инструментов - позволяет переключаться между разными инструментами, например VS, VSCode, Xamarin и т. Д.
  • Существующие инвестиции - у крупных клиентов есть существующие сборки, которые нельзя выбрасывать.
  • «Мышечная память» - Люди привыкли к MSBuild

Аргументы против

  • Существующие инвестиции - инвестиции, сделанные в инструментарий .NET Core: post RC. RC _должен_ означать отсутствие серьезных критических изменений
  • Противно CSProj / MSBuild - прошлый негативный опыт работы с csproj и MSBuild
  • Шаг назад - переход на project.json был переходом к новому способу работы, отчасти для привлечения нового поколения разработчиков. Это отменяется

Мнение
Я оплатил полную подписку SurveyMonkey, поэтому я могу получить доступ к полному набору результатов (а не к первой сотне). Это 321 ответ, что обычно соответствует погрешности ± 5,5%, 95% достоверности для 9 миллионов человек.

Общие аргументы, которые я слышал против этого опроса, следующие:

  • Вопросы / ответы предвзяты: я в это не верю, и даже если они верны, их не так уж много. Существует широкий спектр ответов.
  • Опрос был опубликован для предвзятой аудитории: Twitter? Последователям различных графиков работы членов команды. Не знаю, как это предвзятая аудитория.
  • Нерелевантно с научной точки зрения: Хорошо, я понял это. Я не проводил полный протокол исследования, поэтому он не прошел экспертную оценку. Это уровень уверенности, необходимый для оценки поддержки предложения?

Они здесь:
image
image
image
image
image

Я призываю всех, кто любит .NET framework, не недооценивать уровень беспокойства по поводу этих изменений, а также принимать во внимание отзывы и взаимодействовать с сообществом по этому поводу на том основании, что их опасения обоснованы и исходят из осознанного опыта. .

И если все равно будет принято решение продолжать, необходимо предоставить более широкий набор аргументов и доказательств, чем это было до сих пор.

Man @shederman напоминает мне (и многих других), когда Silverlight ел его , за исключением x10 и более сосредоточенных / опытных. Наверное, поэтому я его поддерживаю: 100:%! ха-ха.

Одна из самых больших проблем MSBuild в его нынешней форме заключается в том, что он объединяет определение проекта с процессом сборки.

Таким образом, добавление процесса сборки в project.json приведет к той же ошибке, что и MSBuild / VS.

Определение проекта должно стоять отдельно от процесса сборки и использоваться в процессе сборки.

: +1:: +1:: +1: ... Отличный способ постановки проблемы !!! Знаете, я так долго засовывался в это, что мне даже в голову не приходило. Но вы (снова) на 100% в курсе.

Я ненавижу открывать файл csproj для решения проблемы, потому что это стена из сложного для синтаксического анализа текста.

Это нужно где-то оформить, @nbarbettini! Прекрасно передает мои настроения.

И на самом деле не имеет большого значения, является ли формат файла JSON, XML или каким-либо другим.

Да, я очень не хочу напоминать людям об этом, но похоже, что некоторые разработчики придерживаются концепции форматов, и это вводит в заблуждение. Парадигма проекта «JSON» на самом деле не является «вещью JSON», но использует JSON в качестве способа сериализации для описания своей «модели». Тот факт, что JSON лаконичен и менее болтлив, чем XML, сделал его еще более привлекательным (для большинства).

Соответственно, MSBuild не основан на XML, как таковой, но способ его разработки заключается в описании «модели» в этом формате. Я говорю «модель», потому что обе эти системы страдают (что я считаю) конструктивным недостатком, заключающимся в размещении модели документа перед фактической моделью / API, которая в конечном итоге десериализуется в память. Это означает, что нужно управлять большим количеством артефактов и концепций, чем действительно необходимо, и в конечном итоге усложняет систему. Жесткое кодирование для приема только определенного формата (XML или JSON) только усугубляет ситуацию, и мы снова должны изучить способы смягчения этого ограничения.

В любом случае, хромое воскресное утро для всех. : stuck_out_tongue:

Я нигде в этой теме не видел этого, так что вот оно ... https://youtu.be/N9MteJH-HsQ. Надеюсь, это немного больше объясняет, почему вносятся изменения.

@shederman

«Могу я из интереса спросить, в чем безумие? Допросить чье-то мышление в наши дни нерационально? Или я что-то забыл?»

Я имел в виду результаты опроса и пытался экстраполировать их на общую популяцию разработчиков. Как я уже упоминал, это примерно эквивалентно опросу собак и кошек на выставке игрушек для кошек, и если предположить, что это применимо ко всей популяции, существует большая и очевидная систематическая ошибка выборки.

GitHub на моем телефоне не позволяет мне +1 @gregoryyoung , но +1.

Команда объяснила, что отчасти причиной изменения является приобретение Xamarin, что имеет большое значение. Потенциал обмена библиотеками между проектами .NET, ASP.NET и Xamarin mobile / x-plat огромен, и если это означает компрометацию формата файла проекта / сборки, это стоящая сделка, IMHO.

Я собираюсь подождать и посмотреть, как выглядят инструменты и окончательная настройка файла, прежде чем я сформирую окончательное мнение.

@gregoryyoung Я имел в виду результаты опроса и пытался экстраполировать их на общую популяцию разработчиков ... существует большая и очевидная систематическая ошибка выборки.

Какой это будет систематическая ошибка выборки? Тот, где он был размещен в основном в Твиттере людей, которым _ нравятся_ изменения? Тот, где это было на слабых каналах, которые использует команда разработчиков?

Основная ошибка выборки, которую я вижу, состоит в том, что респонденты, вероятно, вовлечены, информированы и увлечены. Конечно, это, скорее всего, не репрезентативный образец, но я бы сказал, что он важный. И даже с учетом систематической ошибки выборки, означает ли это, что результаты нужно выбросить? Что точки зрения респондентов не имеют значения?

Свое мнение высказали 322 профессиональных разработчика .NET. Собираетесь ли вы полностью игнорировать их мнение, потому что считаете (без каких-либо доказательств в поддержку вас), что он нерепрезентативен?

Судя по всему, на следующей неделе появится сообщение в блоге, тогда у нас будут более конкретные вещи для обсуждения.

Черт возьми, люди должны успокоиться :)

Я согласен, что это изменение кажется большим, но я думаю, что оно повлияет на людей намного меньше, чем может показаться. Помните, что, когда команда говорит об «инструментах», это также включает cli. Любое преобразование, которое должно произойти, также будет выполнено с помощью cli, «инструментария» для добавления ссылок, который, как я считаю, даже лучше, чем вводить их в json или xml, будет в cli. Глобализация уже поддерживается в msbuild. Msbuild, очевидно, будет включен в не sdk, поэтому дополнительных установок не будет, история нового проекта также будет такой же, команды dotnet просто будут делать другие вещи под капотом. (Я не микрософт, но это кажется весьма вероятным)

Команда не идиоты, они не слишком легкомысленно относятся к этому изменению. Они _приведены_ причины, в первую очередь совместимость и согласованность с остальной частью платформы на разных языках, собственные ссылки и типы проектов, степень детализации пакетов nuget и так далее. Прошла всего неделя, и они сказали, что очень скоро детализируют изменения и свои доводы.

Я бы хотел, чтобы люди хотя бы подождали этого и каковы их настоящие планы, прежде чем полностью осудить этот шаг.

И да, я вручную отлаживал файлы csproj / tfproj и боролся с условными правилами для включения файлов и всего прочего. Черт возьми, я даже написал пользовательские задачи сборки. Но, в конце концов, гораздо проще абстрагироваться от сложной системы с помощью простых инструментов (включая cli), чем заставлять относительно простую систему project.json поддерживать все сложные сценарии, которые ей необходимо поддерживать.

Другими словами, та простота, которую любили люди в project.json, уже ушла, она должна была поддержать сложную реальность обобщенной среды dotnet со всеми видами или проектами и сценариями. Если бы они реализовали все это в project.json, вы бы снова получили msbuild. Я предпочитаю, чтобы они сделали шаг назад и посмотрели на систему сборки в целом, а не добавляли функцию за функцией в project.json, пока она не превратилась в большой клубок спагетти.

Давайте просто посмотрим, что они предлагают, а затем поднимем конкретные вопросы, если мы найдем в этом недостатки :)

@ aL3891

Если команда четко объяснит свои аргументы и альтернативы, которые были рассмотрены, и почему они были отклонены, а также рассмотрит и поддержит предложения, которые были предложены здесь, тогда я буду рядом с этим и поддержу любое хорошо аргументированное решение, которое выходит из такого процесса.

Фактически, это именно то

Если получим, от меня +10.

@ aL3891 Быстрый вопрос. Некоторые люди говорили, что мы должны присутствовать на митинге в среду, чтобы решить эти проблемы. Вы хотите сказать, что нам лучше дождаться публикации в блоге?

Всем также следует помнить, что это все с открытым исходным кодом. Если вы уверены, что не-msbuild лучше, просто разветвите существующий инструментарий и продолжайте работать. Как и у всех интересных вариантов дизайна программного обеспечения, есть свои плюсы и минусы для всех сторон аргумента. Microsoft должна реагировать на своих крупных платежеспособных клиентов, но надо отдать им должное, они сделали все это с открытым исходным кодом. Если что-то еще работает у вас, сделайте это.

Я смотрел видео на YouTube, которое опубликовал

Вдобавок идея заново изобрести колесо не казалась привлекательной, когда казалось, что это было действительно правильным решением ... но снова в наследство.

У меня есть новая критика использования MSBuild, основанная на стояке .NET - тогда как у нас есть хорошее разделение проблем в ряде мест, MSBuild - нет. Грубо говоря, согласно стендапу, он каким-то образом должен знать обо всем, чтобы быть эффективным, и просто оркестровка разных произведений недостаточно.

Между тем, и я думаю, что это должно быть в другой теме - похоже, есть «внутренние инженерные решения», которыми позже делятся с сообществом. Это заставляет меня думать, что MS не получает полностью открытый исходный код - если бы у них были эти обсуждения открыто (и чтобы люди знали, что они происходят), это было бы меньшим сюрпризом, и у нас, возможно, уже были бы ответы, и множество заинтересованных сторон (и я имею в виду клиентов, на которых может негативно повлиять отказ от MSBuild) могли бы четко заявить о своей позиции раньше, и сообщество могло бы более своевременно отреагировать на проблемы / проблемы и даже решения для проблемы ... Вместо этого, «это был наш единственный вариант», поэтому вы открываете исходный код не только программного обеспечения, но и процесса разработки. Таким образом, должно работать изречение: «Если хватит глазных яблок, все ошибки мелкие». Я не знаю, насколько велика команда инженеров в MS, но она меньше, чем сообщество в целом, и в сообществе есть несколько действительно хороших талантов, которые могут принять вызов, например, тот, который команда инженеров решила неработоспособным. ... и это, вероятно, для них, но не для сообщества в целом. Открытый исходный код - это использование незадействованных ресурсов и талантов.

С другой стороны, может я что-то где-то упустил?

@shederman Я бы посоветовал тем, у кого есть личный интерес, присутствовать на стендапе и следить за публикацией в блоге (ссылка на которую почти наверняка будет здесь).

Для тех, кто не знает о стендапе, перейдите сюда: https://live.asp.net/

Вы можете добавить его в свой календарь, и за ним стоит посмотреть, даже если вас не волнует изменение определения проекта.

@shederman Я не считаю, что у меня действительно есть право

Последний эпизод на сайте , ссылка на который приведена выше, дала некоторые полезные сведения.

Также есть репозиторий системы проектов roslyn, который, скорее всего, увидит много действий в ближайшие месяцы.

Есть ли у кого-нибудь TL; DR в эпизоде ​​on.net?

Я думаю, что я очень необычно _hating_ смотрю видео о программировании. Отправь мне текст в любое время 😄

Чертов адский огонь! Я даже не использую IDE в своих методах обучения 😱

Я считаю, что очень необычно ненавижу смотреть видео о программировании. Напишите мне в любое время: smile:

В чем проблема? Это всего лишь час вашего времени. :ухмылка:

@rhires

Чувак. Возможно, это один из лучших постов, которые я видел по этому поводу за последние 3 дня!

Маленькая цена, которую нужно заплатить, чтобы оставаться на переднем крае, imo, но каждому свое;)

Базовый tl; dr:
Команда начала получать отзывы как от внутренних клиентов, таких как xamarin, так и от внешних, о том, что миграция существующих проектов на project.json была сложной и заставляла project.json работать вместе с существующими проектами, а также с другими инструментами, такими как собственные и другие. такие платформы, как android, означают привлечение значительного количества кода (или концепций) из msbuild. Это потребует много времени и усилий и сократит выпуск на неприемлемое количество времени, а также замедлит будущую работу (в том числе для других продуктов, таких как xamarin studio и mono development, а также разработчиков плагинов Visual Studio).

Поэтому вместо этого они решили вместо этого основать систему сборки на msbuild, но привнести то, что нравится людям, из новой системы. Что касается сроков, то приобретение xamarin не было известно даже при создании RC1, но теперь, когда оно было сделано, многое изменилось.

Они также признают, что люди очень любят project.json, и они тоже, и что они хотят сохранить как можно больше от этого, возможно, даже позволяя msbuild читать файлы project.json через целевой объект. Сценарии без Cli и VS - это также то, что они считают основным сценарием. Они также немного говорят о других системах сборки, и цель состоит в том, чтобы дать людям возможность использовать другие вещи, кроме msbuild, если они хотят.

Затем они рассказывают немного о RC2 и о том, что там поставляется, а также размышляют о том, что они могли бы сделать по-другому в отношении миграции системы проекта, быть более открытыми раньше и иметь больше разговоров на GitHub и так далее.

Я действительно рекомендую его посмотреть, я, вероятно, упускаю некоторые тонкости здесь.

@ aL3891 - спасибо за отличное резюме. Просматривать видео было утомительно. Я согласен, что они должны написать текстовое резюме. Я заметил, что они «учатся», и им все еще неудобно открывать свой процесс, даже если они говорят, что это хорошо. Надеюсь, это будет для них хорошим опытом обучения, и мы увидим изменения и извлечем из этого пользу.

@ aL3891 Спасибо за резюме!

Маленькая цена, которую нужно заплатить, чтобы оставаться на переднем крае, imo, но каждому свое;)

Ах, но я не на переднем крае, я остаюсь немного назад от там. Достаточно далеко назад, чтобы не порезаться, по крайней мере, так я думал, когда принял .NET Core post-RC1 😢

@shederman , учитывая , что «пост-RC1» в основном nightlies или источник, как именно вы , как ваш стейк?

@neoKushan Я имел в виду, что мы только "приняли * .NET Core. После того, как_ был выпущен RC1. Мы все еще находимся на ванильном RC1.

Итак, нам нравится наш стейк средней прожарки. Но мы просто нарезаем действительно сырое мясо и зовем официанта.

Но все в порядке, я перестал звать официанта, а теперь позвонил maitre'd (нашему представителю партнеров Microsoft Group), чтобы они пришли навестить меня, и мы сможем обсудить принятие решений, распространение информации и направление платформы.

Мы ничего не знаем!

Нам не было предоставлено достаточно информации, слишком много теории и предположений в этом вопросе. Краткое содержание для ленивых, которые не хотят читать эту ветку:

Что мы знаем

  1. xproj будет преобразован в csproj.
  2. У нас может быть файл nuget.json.
  3. Мы используем msbuild .
  4. Все это будет происходить поэтапно.
  5. Библиотеки не изменятся.
  6. Вам не нужно указывать каждый файл в csproj.

Чего мы еще не знаем

  1. Будет ли csproj компилироваться в .nupkg?
  2. Будет ли csproj компилироваться сразу для нескольких архитектур и целей x86 / x64 dotnet / dotnetcore?
  3. Будет ли отдельный файл nuget.config.
  4. Как будут обрабатываться команды для выполнения npm / gulp / bower / и т. Д.?
  5. Сможем ли мы использовать dotnet build а также msbuild ? Я полностью за «один .net», к которому стремится
  6. Останется ли intellisense для ссылок на проекты или исчезнет?
  7. Будет ли инструмент VS или командная строка достаточно хорошими, чтобы нам никогда не пришлось редактировать csproj.
  8. Получим ли мы инструменты за dotnet add reference MyAssembly ?

Я думаю, что этот вопрос следует закрыть, пока у нас не будет дополнительной информации.

Я полностью за «один .net», к которому стремится

Этот ? : smile:: +1:: +1:: +1:

Я думаю, что этот вопрос следует закрыть, пока у нас не будет дополнительной информации.

но но ... тогда что я буду делать со своей жизнью ??? : cry:: grin:

@RehanSaeed

А что, если у меня проблемы со списком «Что мы знаем»?

Должен ли я дождаться ясности в списке «Чего мы еще не знаем», прежде чем выражать свои опасения?

Или я должен просто заткнуться и засосать?

Насколько я знаю, очень многие хотели бы ... 😉

Из всего, что я видел, решение на 100% неизменное:

image

Так что еще мне нужно от "Чего мы еще не знаем"?

@shederman Вы действительно можете посмотреть видео в сети. Это дает множество аргументов в пользу этого решения.

к сведению: я обычно меняю скорость на 1.5, чтобы быстрее смотреть. https://www.youtube.com/watch?v=N9MteJH-HsQ

Если мы собираемся остаться с файлом проекта на основе XML, пожалуйста, ПОЖАЛУЙСТА, можете ли вы предложить / поддержать / потребовать, чтобы инструменты поместили содержимое файла в некотором порядке. И «хронологический» порядок НЕ является приемлемым. Самая большая проблема, с которой я столкнулся с файлами proj, - это сложность их объединения. Просто расположите их хотя бы в алфавитном порядке. Да, у нас все еще будут периодические проблемы со слиянием, но я всегда буду использовать «случайные» вместо «вездесущие».

@MelGrubb, единственное, что мы знаем, это то, что в новом макете проекта НЕ будут перечислены все имеющиеся файлы, это будет точно так же, как это делает project.json.

Для всего, что предполагается управлять вручную, пожалуйста, TOML.

JSON не имеет никакого смысла для настройки. В нем даже меньше смысла, чем в XML.

Для всех, кто интересуется, похоже, что биты RC2 доступны (я пока не вижу сообщения в блоге)

https://www.microsoft.com/net/core#windows

и https://www.microsoft.com/net/download#core

Мои два цента, черт возьми:

Мне понравилась простота project.json. Вот что я хотел бы (и не хотел) видеть в инструментах на основе MSBuild:

  • MSBuild не должен быть привязан к VS или любой другой среде IDE / редактору. Это должен быть отдельный инструмент, который можно установить отдельно. (Или включен как часть установки dotnet cli.) Я говорю это, потому что мне пришлось установить полный экземпляр VS на агенты сборки только для того, чтобы получить MSBuild. Для меня это никогда не имело смысла.
  • Сам MSBuild (или dotnet cli, содержащий MSBuild) должен быть установлен с помощью командной строки - будь то apt-get, chocolately, homebrew, powershell или bash / curl. Если я не могу установить это как часть полностью автоматизированной установки агента сборки (например, в circle.yml или Dockerfile), это будет препятствием и источником боли.
  • MSBuild должен быть очень дружелюбным к командной строке. Я должен иметь возможность делать что угодно из командной строки - и, следовательно, иметь возможность автоматизировать что-либо в процессе сборки - в circle.yml, bash или другом файле сценария. И я хотел бы видеть хорошее использование stdin и stdout, чтобы я мог вводить / выводить команды MSBuild.
  • Работа над проектом .NET Core в VS Code (или другом редакторе, отличном от VS) не должна требовать специфичной для VS информации в файле csproj или где-либо еще. Информация о проекте, зависимости пакетов nuget, цели платформы, директивы компилятора и т. Д. Должны быть доступны разработчикам, использующим разные IDE / редакторы. Это имеет смысл в файле проекта. Но люди, не использующие VS, не должны видеть настройки инструментов VS - они находятся в отдельном файле.
  • Файл (ы) проекта должен быть простым для понимания и легким редактированием вручную. Инструменты замечательные, но я должен быть в состоянии открыть файл и понять, что они делают за меня. И легко вносить изменения.
  • Хотя я знаю, что разницы в функциональности / возможностях нет, я лично предпочитаю json, а не xml. Я также думаю, что использование json поможет привлечь разработчиков из других стеков. Достаточно сложно привлечь людей к .NET, не сделав одной из первых вещей, которые они видят в большом, трудно поддающемся расшифровке XML-файле. (Это более эмоционально, чем логично, но я думаю, что это имеет значение.) Пожалуйста, по крайней мере сделайте json опцией и используйте эту опцию в генераторах yeoman и других новых шаблонах проектов. В худшем случае, пожалуйста, быстро примите неизбежный запрос на перенос, реализующий простой формат json в репозитории MSBuild.
  • Было бы неплохо сохранить «скрипты» в стиле npm, чтобы я мог легко делиться командами, используемыми для разработки, тестирования, отладки, сборки, запуска, сборки / запуска докеров и т. Д., С моей командой. Они могут находиться в своих собственных файлах сценария, но они имеют смысл (для меня) как часть файла проекта.

@jtbennett

«Но люди, не использующие VS, не должны видеть настройки инструментов VS - они находятся в отдельном файле».

Просто чтобы добавить, теперь есть куча вещей в других файлах, которые, вероятно, должны быть помещены в файл msbuild. Игнорированные вещи - хороший пример того, что файлы проекта по-прежнему поддерживаются. Я не могу сказать вам, сколько проектов я видел, построенных в VS, но не из командной строки.

@jtbennett

MSBuild не должен быть привязан к VS или любой другой среде IDE / редактору.

Он вообще не будет привязан к VS, он будет доставлен через Nuget, поэтому он ни к чему не привязан.

Сам MSBuild (или dotnet cli, содержащий MSBuild) должен устанавливаться из командной строки.

С сегодняшнего дня это не изменится, вы по-прежнему сможете установить dotnet cli из обычных источников пакетов.

MSBuild должен быть очень дружелюбным к командной строке.

_MSBuild_ будет фактически частью самой сборки, поэтому я не думаю, что вам нужно будет передавать параметры командной строки. Однако донет (CLI), очевидно, будет дружественным к командной строке, и я думаю, что это все, что вам нужно / нужно.

Работа над проектом .NET Core в VS Code (или другом редакторе, отличном от VS) не должна требовать специфичной для VS информации в файле csproj или где-либо еще.

Я полностью согласен с этим. Надеемся, что «новый» формат проекта будет намного упрощен.

Файл (ы) проекта должен быть простым для понимания и легким редактированием вручную.

Они сказали, что для них это тоже приоритет.

Хотя я знаю, что разницы в функциональности / возможностях нет, я лично предпочитаю json, а не xml. Я также думаю, что использование json поможет привлечь разработчиков из других стеков. Достаточно сложно привлечь людей к .NET, не сделав одной из первых вещей, которые они видят в большом, трудно поддающемся расшифровке XML-файле.

Мне это интересно, я лично считаю, что XML намного легче расшифровать, чем JSON, но я думаю, что во многом это зависит от того, насколько хорошо спроектирована схема (для любого из них). В прошлом мне приходилось расшифровывать ужасный XML с действительно ужасными именами элементов (например, «Element»), и хотя MSBuild ни в коем случае не является худшим нарушителем в этом отношении, он определенно оставляет желать лучшего. В случае JSON с именем ключа могут возникнуть те же проблемы.

Как ни странно, мне недавно пришлось работать над проектом, в котором кто-то пытался встроить JSON в элементы XML :(

Опубликована запись в блоге RC2: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

Основная публикация .net также опубликована https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

Спасибо @neoKushan !

@michaelvolz Я не думаю, что этот файл останется, если верить этому: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server (old: gcServer) - логическое значение, указывающее, следует ли использовать GC сервера (по умолчанию: true).

и

Мы могли бы использовать другой формат для файла deps, но если мы уже интегрируем парсер JSON в хост, кажется наиболее подходящим повторно использовать его здесь.

Кажется немного странным для них иметь XML для _project config_, но .json для _runtime config_?

Кажется немного странным для них иметь XML для проекта, но .json для среды выполнения?

А теперь? :смеющийся:

@ Mike-EEE Хороший момент! Я обновился, чтобы, надеюсь, прояснить, что я имел в виду: поцелуи:

@neoKushan нет, в первый раз ты был прав. : smile: Я соглашался с вами в своей язвительной, пограничной-контрпродуктивной манере. : smirk_cat:

Но да ... 100% согласие с тем, что наличие разных форматов в решении сводит с ума. Наличие единого формата во всех направлениях снижает сложность, переключение контекста и, следовательно, _ путаницу_. Это одна из причин, по которой я хочу, чтобы MSBuild включал разные форматы и стал независимым от формата . Ой, предупреждение, бессовестная вилка. :ухмылка:

Думаю, я буду последователем вашего святого крестового похода @ Mike-EEE, раз уж мы застряли с msbuild, давайте сделаем его лучше.

Привет, спасибо @sandorfr ... пожалуйста, не стесняйтесь участвовать в этой теме (даже если это реакция /: + 1 :). Я чувствую себя немного одиноким и определенно иду на спорную территорию! С моей точки зрения, я был бы очень открыт для улучшения своего продукта, чтобы увеличить его принятие / предпочтение / удобство использования / симпатию, если бы множество клиентов были вынуждены использовать мой продукт по какой-либо причине. Но я не отвечаю за это, так что. : stuck_out_tongue:

@ Mike-EEE Я прочитал кое-что из этой ветки, я сейчас так подавлен ... Вы вошли в мир унаследованных умов: D.

Будем надеяться, что люди в Microsoft будут более открыты для ваших идей, потому что на самом деле меня устраивает msbuild, только если все станет более простым и понятным, и мне не нужен графический интерфейс для редактирования моего проекта (да, json intellisense был намного лучше чем обычные вкладки проектов Visual Studio).

Вы вошли в мир наследия унаследованных умов: D.

Хорошо-сказал @sandorfr ... хорошо-сказал.

Для тех, кто не знает о стендапе, перейдите сюда: https://live.asp.net/

Хорошо, я полный бездельник и, наконец, проверил это только сейчас. Похоже, следующий стендап состоится на следующей неделе? Команда пропускает эту неделю?

@ Mike-EEE Интересно, в какой-то момент это было определенно запланировано на сегодня вечером, но мне интересно, изменилось ли оно. Я написал в Твиттере @shanselman , надеюсь, это просто ошибка, но, учитывая, что RC2 вышел только вчера, они вполне могут захотеть пропустить его на этой неделе.

Ладно, круто @neoKushan ... просто убедись, что здравомыслие прикручено ко мне на голову. Чтобы быть уверенным, я бы тоже не хотел так быстро реагировать на все наши вопросы и недовольство. :подмигивание:

из Slack:

jongalloway [9:31 AM] Я почти уверен, что завтра ASP.NET Community Standup отменяется - и шансельман, и дамианедвардс находятся в OSCON.
...
davidfowl [9:34 AM] damianedwards: вернулся ... но шансельман на оскон
...
jongalloway [9:46 AM] Да, стенд сообщества ASP.NET определенно отменен на 17 мая. Я обновил сайт.

@ Mike-EEE разбирается со всем нашим ... недовольством

😆

image

Если остались сомнения: https://twitter.com/shanselman/status/732585321775267842

надо пропустить. Я на #vslive и на OSCON

В project.json мне очень нравится одна вещь: все файлы включаются в проект по умолчанию, без необходимости явно включать каждый из них. С большими проектами (я имею в виду тысячи файлов) процесс слияния был действительно болезненным из- за XML, но также и из-за того, что каждый файл был указан в csproj.

Знаем ли мы, будет ли какое-то улучшение с этой стороны?

@pierrus Было упомянуто, что они не хотят возвращаться к тем временам, когда все файлы были перечислены внутри csproj.

@MaximRouiller ОК, не знал этого, отлично!

@MaximRouiller но они хотят , чтобы вернуться в те дни , когда MSBuild было одно кольцо ™, я имею в виду инструмент для сборки. 😉

_Ash nudertog vegal durbatulûk, ясень nudertog vegal gimbatul,
пепел нудертог вегал thrakatulûk agh burzum-ishi krimpatul._

@shederman Я модерировал свою точку зрения с момента моей первой реакции на новость.

Я думаю, что они изначально хотели отправить формат project.json , но нормализация модели с помощью csproj / Xamarin просто потребовала бы от них продвигать фреймворк еще дольше. Более быстрым достижением было повторное слияние с csproj. Они могли сохранить новый способ в отдельном файле, сохраняя при этом чистые «только данные» внутри csproj. Это для меня объясняет огромную работу RC2, которая была проделана.

Если вы переместите свойства, которые почти не меняются, и сохраните классные новые функции в отдельном файле? На самом деле мы ничего не теряем. Да, мы возвращаемся к монстру ... но мы не так уж далеко.

У меня нет никаких инсайдерских знаний по этому поводу. С моей стороны это чистое предположение.

В любом случае ... мы больше не заканчиваем годовым циклом выпуска. Если они готовы перейти с project.json на csproj после RTM, я предполагаю, что более крупные изменения могут быть выпущены и после RTM.

Изменения, о которых не знает никто, кроме команды MS.

@MaximRouiller Я не могу отрабатывать "возможные" изменения, которые _могут_ произойти.

Я просто работаю над анонсированными изменениями, они переходят с облегченной сборки на использование MSBuild и xproj для всего.

Да, мы возвращаемся к монстру ... но мы не так уж далеко.

Гм, если мы _ устарели_ что-то, что работает в 90% случаев использования, чтобы переместить _ назад_ к чему-то, что слишком сложно для этих вариантов использования, что ж, у меня есть только один вопрос:

Почему?

Почему dotnet build вызывает MSBuild, когда msbuild уже делает это достаточно хорошо. Зачем не рекомендовать простую сборку? Зачем делать лишнюю работу? Единственная причина проста: было принято решение, что мы все должны использовать MSBuild постоянно, для всего, навсегда.

то, что работает в 90% случаев использования

[нужна цитата]

Даже если предположить, что это 90% случаев использования, станете ли вы работать с чем-либо, что дает сбой в 1/10 случаев?

вернуться к чему-то слишком сложному

Опять же, [необходима цитата], единственное, что мы пока знаем, это то, что это будет XML-csproj и что он не будет содержать список файлов. Мы больше ничего не знаем о том, как будет работать система, и я не уверен, что нам это вообще нужно знать, потому что все здесь просто называют «сборку dotnet», и независимо от того, как выполняется сборка, это не изменится.

Почему сборка dotnet вызывает MSBuild, когда msbuild уже делает это достаточно хорошо.

Ушли ли мы от утверждения, что MSBuild «слишком сложен», до «MSbuild уже справляется с этим достаточно хорошо»? В настоящее время dotnet build просто _просто, потому что все, что происходит в фоновом режиме, скрыто от вас. Переход на MSbuild не меняет этого, насколько вы понимаете, это все еще dotnet build .

Для тех, кто постоянно повторяет, что между системой проекта и системой сборки должно быть различие, вы не желаете признать, что на самом деле существует разница между наличием файлов XML MSBuild в качестве системы проекта и наличием MSBuild в качестве системы сборки - вот и все. это уже разделение.

работает в 90% случаев использования

@shederman Пожалуйста, перестаньте считать, что все работает на ASP.NET ... В этой ветке вы произвольно считаете, что невежественны. Я предлагаю вам пока успокоиться, пока мы не получим больше информации о новой системе проектов, вместо того, чтобы просто предполагать, что все обречено.

@shederman Причина, по которой вы устанавливаете прокладку поверх чего-либо, заключается в том, что вы хотите ее заменить. Абстрагируйте его, чтобы вы могли изменить реализацию. Мы делаем это каждый день. Это называется рефакторингом.

Надеюсь, его заменили. Если я правильно помню, помимо XML, он еще и медленный по сравнению с другими вещами.

Если это будет похоже на dotnet build вопрос в том, насколько сложно будет изменить процесс сборки подчеркивания? Можно ли заменить msbuild на что-то другое? Сколько на это потребуется клейких лент?

Если бы мы могли сделать такую ​​замену в 1 или 2 мотках клейкой ленты, это было бы приемлемо.

@neoKushan Ушли ли мы от утверждения, что MSBuild «слишком сложен», до «MSbuild уже справляется с этим достаточно хорошо»?

Гм, нет. Мне кажется, я говорил, что команда msbuild неплохо запускает MSBuild. Я не делал никаких выводов о MSBuild как об инструменте. Это было непонятно?

@neoKushan Даже если предположить, что это 90% случаев использования, стали бы вы работать с чем-либо, что

Никто ничего не говорит о том, что что-то не работает . Некоторые инструменты больше подходят для одних целей, чем другие. Я бы сказал, что мощность и сложность MSBuild подходят примерно для 10% сборок. Мы можем спорить о точных процентах, но это определенно меньше 100%.

@neoKushan Переход на MSbuild не меняет этого

Гм, это не меняет процесс сборки, нет. Однако он _изменяет_ то, что необходимо для работы процесса сборки (например, файл csproj), и скорость, с которой он выполняется.

@neoKushan, вы не согласны с тем, что на самом деле существует разница между наличием XML-файлов MSBuild в качестве системы проекта и наличия MSBuild в качестве системы сборки - разделение уже существует.

Извините, но я не понимаю, что когда один инструмент выполняет две задачи, это разделение.

@poke Пожалуйста, перестаньте считать, что все работает на ASP.NET

Я не. Я говорю, что предлагаемое решение не очень хорошо работает для простых сборок. Некоторые из них являются сборками ASP.NET. Лично я не понимаю, почему мне нужно что-то столь же мощное, как MSBuild, для простого консольного приложения.

@poke В этой ветке вы

Надеюсь, да. Потому что я сознательно игнорирую те замечательные преимущества, которые получают пользователи MSBuild.

@poke Я предлагаю вам пока успокоиться, пока мы не получим больше информации о новой системе проектов, вместо того, чтобы просто предполагать, что все обречено.

Чувак, я спокоен, обещаю тебе.

Я просто не позволяю, чтобы точки зрения, с которыми я не согласен, не оспаривались. Обещаю, это не признак волнения. Ради всего святого, меня даже не взволновал какой-то

Какая-то ирония, когда этот тот же маленький придурок _person_ призывает меня успокоиться.

Действительно забавно.

@MaximRouiller @shederman Причина, по которой вы устанавливаете прокладку поверх чего-либо, - это когда вы хотите ее заменить. Абстрагируйте его, чтобы вы могли изменить реализацию

Ах да, и это было бы хорошей причиной для этого, за исключением того, что я слышал, нет никакого намерения заменять MSBuild. Это выбранная система сборки в обозримом будущем. Я бы хотел, чтобы мы позволили проектам работать без элементов, специфичных для MSBuild, и если бы dotnet build либо выполнял существующую облегченную сборку, либо выбирал инструмент сборки на основе чего-либо, например config. Если вы хотите использовать MSBuild, обязательно создайте файл msbuild и запустите msbuild .

Гм, нет. Мне кажется, я говорил, что команда msbuild довольно хорошо запускает MSBuild.

Чтобы поместить это в контекст:

Почему сборка dotnet вызывает MSBuild

dotnet build делает гораздо больше, чем «просто» вызывает компилятор, взгляните на текущую реализацию сборки dotnet в интерфейсе командной строки . Создание одного проекта - это всего лишь часть процесса dotnet build . В конце концов _part_ этого процесса будет вызывать msbuild но это не ваша работа, это работа CLI.

Я не делал никаких выводов о MSBuild как об инструменте.

Все, что вы сделали в этой теме, - это оценили MSBuild как инструмент. Честно говоря, абсурдно утверждать, что вы этого не делаете.

Это было непонятно?

Очень мало из того, что вы говорите, ясно или, по крайней мере, хорошо продумано.

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

Таким образом, некоторые инструменты не соответствуют назначению.

Я бы сказал, что мощность и сложность MSBuild подходят примерно для 10% сборок.

Что ж, это интересно, потому что каждый разработчик Visual Studio .NET должен не согласиться. Фактически вы говорите, что MSBuild бесполезен для 90% пользователей (игнорируя тот факт, что вы вытаскиваете цифры из своей задницы), что - опять же - смехотворно.

Гм, это не меняет процесс сборки, нет.

Если процесс не изменился, то ваш единственный аргумент в том, что вам не нравится структура проекта - поэтому тот факт, что это MSbuild или что-то еще, что скрывается за капотом, совершенно не имеет значения .

Однако он меняет то, что необходимо для работы процесса сборки (например, файл csproj).

Это буквально единственное, что действительно меняется, насколько люди видят.

и скорость, с которой это выполняется.

[нужна цитата]

Пожалуйста, покажите мне, насколько новый процесс быстрее или медленнее, учитывая, что в настоящее время его не существует .

Извините, но я не понимаю, что когда один инструмент выполняет две задачи, это разделение.

Поскольку один инструмент не выполняет двух функций, MSBuild может быть системой сборки, но изменение связано с системой проекта. Абсолютно ничего не мешает вам использовать другую систему сборки, если хотите, это просто нетривиально.

Я не. Я говорю, что предлагаемое решение не очень хорошо работает для простых сборок.

dotnet new
dotnet restore
dotnet build

Пожалуйста, покажите мне, как предлагаемое решение что-то меняет в сценарии "простой сборки".

Некоторые из них являются сборками ASP.NET.

yo asp-net web
dotnet restore
dotnet build

Лично я не понимаю, почему мне нужно что-то столь же мощное, как MSBuild, для простого консольного приложения.

Вы этого не сделаете. Вам просто нужно dotnet build . Которая останется у вас. Там ничего не меняется.

Я спокоен, обещаю тебе.

маленький придурок

: -1:

@neoKushan Было бы здорово, если бы вы могли понять концепцию между ответом на цитируемый отрывок и комментарием ко всему обсуждению. Я предполагаю, что вы _способны_ сделать это, поэтому единственный вывод - это намеренно. Если так, просто дать вам понять, что это интеллектуально нечестная тактика. Я надеюсь, что вы это знаете, но здесь я допускаю преимущество сомнения.

Я также считаю, что тебе обязательно стоит принять таблетку от холода. Мы просто обсуждаем то, что, по нашему мнению, лучше всего подходит для фреймворка, мы не пытаемся бороться друг с другом. Атакуйте аргумент, а не человека. Что ж, это то, что я _пытался_ делать уже несколько дней (за исключением одного недавнего случая, см. Ниже).

Что ж, это интересно, потому что каждый разработчик Visual Studio .NET должен не согласиться.

Забавно, я собрал доказательства, которые говорят о другом. Где ты взял свой?

Поскольку один инструмент не выполняет двух функций, MSBuild может быть системой сборки, но изменение связано с системой проекта. Абсолютно ничего не мешает вам использовать другую систему сборки, если хотите, это просто нетривиально .

Ага. Так что согласны. Мне бы очень, очень понравилось, если бы это было тривиально.

Это действительно такое необоснованное запрос? Действительно?

Вы этого не сделаете. Вам просто нужна сборка dotnet. Которая останется у вас. Там ничего не меняется.

И что именно сделает dotnet build ? Раскрыть msbuild ? Почему мы не можем просто использовать msbuild если мы хотим использовать MSBuild? Какова именно цель dotnet build в этой ситуации? Что это добавляет к инструментам?

маленький болван 👎

Попытка пошутить, но вы, наверное, правы.

@poke Я безоговорочно прошу прощения.

Было бы очень хорошо, если бы вы могли понять концепцию между ответом на цитируемый отрывок и комментарием ко всему обсуждению. Я предполагаю, что вы способны на это, поэтому единственный вывод - это намеренно. Если так, просто дать вам понять, что это интеллектуально нечестная тактика. Я надеюсь, что вы это знаете, но здесь я допускаю преимущество сомнения.

Буквально не понимаю, о чем вы говорите.

Я также считаю, что тебе обязательно стоит принять таблетку от холода.

...

Атакуйте аргумент, а не человека.

: InsertRolleyEyeEmoticon Здесь:

Забавно, я собрал доказательства, которые говорят о другом. Где ты взял свой?

Итак, откуда взялась цифра 10% / 90%?

Ага. Так что согласны. Мне бы очень, очень понравилось, если бы это было тривиально.

Это не имеет ничего общего с их переходом на msbuild, у вас уже будут проблемы с заменой текущей системы сборки с dotnet build .

И что именно будет делать dotnet build? Выпустить в msbuild?

Чем отличается dotnet build вызова msbuild вместо dnx или roslyn?

Почему мы не можем просто использовать msbuild, если мы хотим использовать MSBuild?

Итак, вы хотите использовать MSBuild сейчас? Ничто вас не останавливает, в наши дни это пакет nuget. Сходить с ума. Я удивлен, что вы даже спрашиваете, учитывая, насколько вы ненавидите msbuild.

Какова именно цель построения dotnet в этой ситуации? Что это добавляет к инструментам?

Мы действительно обсуждаем достоинства dotnet build ? Вам не нравятся dotnet build ? Вы не понимаете цель dotnet build ? Это маловероятно. Что вы пытаетесь спросить?

@neoKushan, пожалуйста, перестань

Итак, откуда взялась цифра 10% / 90%?

Это исходило из моего личного опыта. Я обнаружил, что около 90% сборок, созданных мной и моей командой за последние несколько лет, не требовали ничего более сложного, чем то, что делает RC1 dotnet build .

Что не имеет ничего общего с их переходом на msbuild, у вас уже будут проблемы с заменой текущей системы сборки на сборку dotnet.

Пожалуйста, поясните, я не совсем понимаю, что вы имеете в виду.

Итак, вы хотите использовать MSBuild сейчас? Ничто вас не останавливает, в наши дни это пакет nuget. Сходить с ума. Я удивлен, что вы даже спрашиваете, учитывая, насколько вы ненавидите msbuild.

_вздох_. У меня вопрос: почему dotnet build должен выводить оболочку в MSBuild, если msbuild уже хорошо с этим справляется? Почему две команды выполняют одно действие?

Я спрашивал об этом примерно три раза, и каждый раз вы либо неправильно это понимали, либо неверно истолковывали.

Я спрашиваю о действиях двух разных команд командной строки
Я спрашиваю, почему оба будут делать одно и то же
Я спрашиваю, если они оба делают одно и то же, почему бы не использовать одну команду?
Я спрашиваю, что вторая команда добавляет к ситуации, если они оба делают одно и то же.
Я не высказываю суждений о качестве основных инструментов в этом контексте, хотя, возможно, я делал это в другом месте.
Указанное суждение в другом месте не влияет на задаваемый вопрос, поскольку задается вопрос о командах командной строки и их действиях, а не о базовых инструментах вообще.
Я не пытаюсь обсуждать, что еще упомянутые инструменты могли или не могли делать в прошлом, просто то, что они предназначены для выполнения в будущем.

Извините за длинное изложение, объясняющее вопрос, состоящий из одного предложения, но, по-видимому, это необходимо.

Статья на InfoQ :
«Microsoft пришла к выводу, что эксперимент project.json провалился, и мы вернемся к использованию файлов .csproj». :разочарованный:

Как я уже сказал, восприятие имеет значение.

У меня вопрос: зачем использовать оболочку dotnet build в MSBuild, если msbuild уже хорошо с этим справляется? Почему две команды выполняют одно действие?

Потому что они не делают чего-то одного?

Зачем MSBuild использовать оболочку csc, если csc уже отлично справляется со сборкой? Почему две команды выполняют одно действие?

Зачем dotnet test shell запускать тестовый запуск xUnit, если он уже отлично справляется с запуском тестов самостоятельно. Почему две команды выполняют одно действие?

Зачем использовать оболочку dotnet restore для NuGet, если NuGet уже отлично справляется с установкой пакетов. Почему две команды выполняют одно действие?

Вы поняли ... (надеюсь: wink :)

@sandorfr

@neoKushan, пожалуйста, перестань

Я не намеренно противодействую кому-либо, я по пунктам разбираю аргумент

Атакуйте аргумент, а не человека.

Хотя на данный момент я даже не совсем уверен, что такое аргумент dotnet build плох.

Продолжаем.

Это исходило из моего личного опыта.

Это ваши «доказательства»? Который, помните, вы выделили жирным шрифтом:

Забавно, я собрал доказательства, которые говорят о другом. Где ты взял свой?

А теперь «Личный опыт». Это то, что мы называем анекдотическими доказательствами.

Я обнаружил, что около 90% сборок, которые мы с моей командой создали за последние несколько лет, не требовали ничего более сложного, чем то, что делает сборка RC1 dotnet.

И что вы ожидаете, что RC2 dotnet build RTM dotnet build или пост-RTM dotnet build изменится в этом отношении?

Пожалуйста, поясните, я не совсем понимаю, что вы имеете в виду.

Кажется, ваш аргумент (и поправьте меня, если я ошибаюсь) выглядит примерно так: «Нетривиально заставить dotnet build делать что-то иное, чем то, на что его запрограммировала Microsoft». Это было нормально во времена DNX, потому что нам всем нравился DNX, но теперь Microsoft хочет использовать MSBuild под капотом, а вам не нравится MSBuild, вам нужна возможность заменить MSbuild на что-то другое - я хотел сказать, что это нет ничего нового, если у вас была проблема с DNX, вы тоже не могли бы это изменить, так что какая бы ни была ваша «проблема» с dotnet build , в этом нет ничего нового, и поэтому я не думаю, что это актуально к _фактическому_ обсуждению здесь, которое представляет собой структуру перехода project.json . csproj

вздох. У меня вопрос: зачем использовать оболочку dotnet build в MSBuild, если msbuild уже хорошо с этим справляется? Почему две команды выполняют одно действие?

@khellang уже ответил на этот вопрос, поэтому я не хочу особо повторяться, но это еще и потому, что я уже довольно кратко изложил, в чем разница (я ненавижу цитировать себя, но не думаю, что вы на самом деле это читали):

dotnet build делает гораздо больше, чем «просто» вызывает компилятор, взгляните на текущую реализацию сборки dotnet в интерфейсе командной строки . Создание одного проекта - это всего лишь часть процесса dotnet build . В конце концов _частью_ этого процесса будет вызов msbuild но это не ваша работа, это работа интерфейса командной строки.

Итак, как минимум в третий раз: вызов dotnet build не является синонимом вызова msbuild . Это не, как вы выразились, «две команды делают одно дело», и никогда не было. Это никогда не входило даже в рамки всей этой дискуссии, но каким-то образом вы оказались там.

Настоящее обсуждение, которое действительно имеет значение, - это структура project.json и то, как ее следует объединить с .csproj. Базовая система сборки в значительной степени не имеет значения, если вам просто нужно что-то простое, потому что у вас всегда будет просто dotnet build .

Итак, как мы можем отличить то, что делает msbuild от того, что делает сборка dotnet сейчас? В чем разница в том, как они работают? Я думаю, что этого не хватает в данном обсуждении. Все, наверное, уже знают, но я думаю, что обсуждение этого вопроса внесет некоторую ясность.

@khellang Мне нравится, как вы это выразили, но, продолжая, я могу настроить, что делает dotnet test . Я могу поместить в project.json другую программу выполнения тестов, отличную от xunit, и dotnet test вызовет эту программу выполнения тестов.

Но все же, судя по тому, что я слышал о грядущих изменениях, в dotnet build не будет аналогичной возможности. Он всегда будет использовать MSBuild для выполнения своих сборок. Это неправильное понимание?

@neoKushan Я никого намеренно не антагонизирую, я по пунктам разбираю аргумент

Ну, по крайней мере, теперь мы знаем, что вы думаете, что делаете. То, что вы _ на самом деле_ делаете, так это искажаете, объединяете позиции, намеренно неверно понимаете вещи и, как правило, ведете себя немного придурком. Ваш тон воинственный, и вы намеренно тупите. Настолько, что мне приходилось пытаться разбить все на одну мысль за раз. Что, как ни странно, вы неправильно истолковали как изменение позиции.

@neoKushan Хотя на данный момент я даже не совсем уверен, что такое аргумент

XML - это плохо. MSBuild - это плохо. Если dotnet build использует только MSBuild, это тоже плохо. Пожалуйста, постарайся не отставать. Это не так уж сложно. Если бы вы не были настолько умышленно тупыми, вы бы поняли это давным-давно и смогли бы внести конструктивный вклад.

@neoKushan Это ваше "доказательство"? Который, помните, вы выделили жирным шрифтом:

Эм нет, это был мой личный опыт, а не доказательства. Мое свидетельство - это 281 респондент из 383, которые считали, что возвращение .NET Core обратно в MSBuild - плохая идея. И 85 из тех респондентов, которые считали, что MSBuild в корне не работает. ЭТО мои доказательства. Где именно твое?

Знаете, чтобы подкрепить ваше заявление о том, что «... _ каждый отдельный_ разработчик Visual Studio .net должен не согласиться»? [Курсив добавлен]

@neoKushan Настоящее обсуждение, которое действительно имеет значение, - это структура project.json и то, как ее следует объединить в .csproj

Я действительно согласен с вами. НО фон критически важен. План, который выразила MS, заключается в том, что MSBuild станет центром вселенной сборки. Мне это не нравится, но давайте продолжим. Учитывая это, возникает простой вопрос:

«Будет ли MSBuild навсегда оставаться основной системой сборки для .NET Framework?»

Если это так, нам нужна только команда msbuild , и нам не нужна команда dotnet build , она совершенно излишняя.

Однако, если мы согласимся с тем, что в какой-то момент MSBuild может не быть _One True Build System_, тогда мы окажемся на более интересной территории. Тогда имеет смысл иметь dotnet build . НО тогда критически важно помнить об этом будущем при обсуждении слияния csproj и project.json.

На что я пытался (возможно, плохо) указать, так это на то, что лучшим (на мой взгляд) вариантом было бы попытаться сохранить четкое разделение между файлами _проекта_ определений_ и _файлами _встроек_. Это лучше подготовит нас к dotnet build который может поддерживать несколько движков сборки. Если вместо этого мы переместим все в csproj, то мы заблокируемся в мире MSBuild.

И да, я понимаю, что в DNX существовала «только одна настоящая сборка». Но тогда я не стал это допрашивать, потому что мне понравился тот билд, который у нас был. Ах, ситуации, в которые мы попадаем, когда беспечно принимаем несправедливость, которая нам _ нравится_ 😉.

Итак, рассмотрим ситуацию, когда у нас есть dotnet build могут использовать один из нескольких инструментов сборки, в зависимости от конфигурации. Так же, как dotnet test может использовать одного из нескольких тестовых исполнителей. Теперь, в таком воображаемом мире, как бы вы теперь объединили csproj и project.json? Это обсуждение, которое я хочу провести.

@rhires С очень высокого уровня dotnet build :

  1. Собирает файлы проекта
  2. Определяет, выполняются ли предварительные условия для инкрементальной сборки
  3. Читает project.json
  4. Определяет целевые фреймворки
  5. По каждому проекту:

    1. Зависимости сборки

    2. Если инкрементальный, проверяет, требуется ли перестройка.

    3. Определяет выходные каталоги

    4. Собирает исходные файлы

    5. Определяет параметры компиляции

    6. Запускает прекомпилированные скрипты

    7. Запускает компилятор с исходными файлами и параметрами.

    8. Запускает сценарии посткомпиляции

    9. Вывод отчетов

@shederman Спасибо! С этого момента, что msbuild будет добавлять / вычитать / заменять в / из / в этом процессе?

Ну, по крайней мере, теперь мы знаем, что вы думаете, что делаете. На самом деле вы искажаете, смешиваете позиции, намеренно неправильно понимаете вещи и, как правило, ведете себя немного придурком. Ваш тон воинственный, и вы намеренно тупите. Настолько, что мне приходилось пытаться разбить все на одну мысль за раз. Что, как ни странно, вы неправильно истолковали как изменение позиции.

Горшок -> Чайник

Вы меняли свою позицию так много раз, что даже не успеваете за собой, вы спорили буквально о каждом аспекте цепочки сборки, демонстрируя, что вы явно не так хорошо понимаете, как все это составляет вместе, как вы _think_ вы делаете, но _I'm_ осел, потому что я осмеливаюсь указать, где ваши аргументы терпят неудачу. Я все еще жду вашего ответа на половину вопросов, которые я поднял выше, но все, что вам нужно сделать, это перейти к другому аспекту процесса сборки.

XML - это плохо. MSBuild - это плохо. Если сборка dotnet использует только MSBuild, это тоже плохо.

Никто, кроме _вы_, не заявлял ничего подобного. Никто. Нет даже малейшего намека на то, что что-то подобное когда-нибудь случится. Я неоднократно говорил вам, что dotnet build не _ просто_ будет вызывать MSBuild , я сказал вам, что dotnet build и msbuild не являются полностью синонимами друг друга, и dotnet build делает намного больше, чем вызов компилятора. Я даже связал вас с чертовым исходным кодом, и другие приходили и говорили то же самое, но вы все еще настаиваете, что это каким-то образом происходит?

Пожалуйста, постарайся не отставать.

Как насчет того, чтобы _вы_ не отставать? Пожалуйста, покажите нам, откуда у вас возникла идея, что dotnet build будет вызывать только msbuild . Кто тебе это сказал? Где ты это читал?

Мое свидетельство - это 281 респондент из 383, которые считали, что возвращение .NET Core обратно в MSBuild - плохая идея. И 85 из тех респондентов, которые считали, что MSBuild в корне не работает. ЭТО мои доказательства. Где именно твое?

И вы вытащили 10% от этих цифр, не так ли? Помните, это ваше заявление:

Я бы сказал, что мощность и сложность MSBuild подходят примерно для 10% сборок.

Позже вы сказали:

Забавно, я собрал доказательства, которые говорят о другом.

Так где это доказательство? Я хотел бы знать, как вы вытащили эту цифру из своих "доказательств".

Знаете, чтобы подтвердить свое заявление о том, что «... каждый разработчик Visual Studio .NET должен не согласиться»?

Легко: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio размещает MSBuild для загрузки и сборки управляемых проектов.

Если вы используете Visual Studio для создания своих проектов, вы используете MSBuild. Даже при работе с ядром .net сегодня даже с RC1 VS использовала MSbuild под капотом. Возможно, вам не понравится MSbuild, но, как я уже сказал, почти каждый разработчик VS использует его, осознают они это или нет.

План, который выразила MS, заключается в том, что MSBuild станет центром вселенной сборки.

Я с этим не согласен. Они никогда не говорили, что это будет центр, все, что они сказали, это то, что некоторые части project.json в конечном итоге вернутся в .csproj - помимо этого, они не сказали ни слова о том, в какой степени это изменяет dotnet build процесс.

«Будет ли MSBuild навсегда оставаться основной системой сборки для .NET Framework?»

Если это так, нам нужна только команда msbuild, и нам не нужна команда сборки dotnet, она совершенно излишняя.

Как уже много раз говорилось, dotnet build и msbuild - это две совершенно разные вещи. dotnet build делает больше, чем просто вызывает набор инструментов компилятора. Цель сборки dotnet - упростить процесс сборки для людей. Увидеть снова:

dotnet new
dotnet restore
dotnet build

Даже если msbuild станет основным компонентом интерфейса командной строки dotnet, это не изменит того факта, что сборка dotnet является чистой и простой оболочкой вокруг того, что является (и всегда будет) довольно сложной системой. Черт, половина причины, по которой существует интерфейс командной строки dotnet (и DNX до него), заключается в том, чтобы уйти от ада аргументов командной строки, которым, в конечном счете, является MSBuild. Ваш аргумент немного похож на высказывание «Зачем нам нужна команда npm install если я могу просто curl пакет?». Конечно, вы можете сделать все это вручную, если хотите, но от этого почти ничего не выиграете. Так что, если dotnet build использует msbuild под капотом? Вы почти наверняка никогда этого не увидите или вам нужно об этом знать.

Вы не можете сравнивать свой старый опыт с MSBuild, он совершенно другой. Мы все (по-видимому) были обожжены этим, потому что мы привыкли открывать VS, создавать проект и просто строить его, но затем, когда вы собираетесь построить тот же проект на сервере сборки, он внезапно жалуется на дерьмо это должно _просто работать_. Вероятно, одна из лучших вещей, которые Microsoft сделала с TFS 2015, - это создание определения сборки, которое связано с _Visual Studio_, а не с _MSBuild_, потому что вы снова к нему "просто работаете". Это именно то, что представляет собой эта цепочка инструментов сборки - dotnet build не предназначена для замены всей вашей системы сборки, она касается только сборки ваших проектов, даже если она использует MSBuild под капотом. Если вы хотите использовать что-то вроде TeamCity или Jenkins, dotnet build - это все, что вам нужно сказать им для вызова, а dotnet сделает все остальное. _How_ это не имеет значения для вас.

Единственное - и я имею в виду это полностью, единственное, что на самом деле меняется для вас, - это файл project.json / csproj. Вот и все_. Вот почему все эти споры о том, что dotnet build самом деле делает MSBuild хорош и чем плох, абсолютно бессмысленны.

@neoKushan, остановись ...

@neoKushan, остановись ...

Часть меня любит представлять, как команда ASP.NET намеренно отменяет стендап, потому что им нравится шоу, и предоставление ответов положит всему этому конец. :улыбка:

С моей (теперь уже твердой) агностической позиции обе стороны в течение некоторого времени казались умышленно тупыми в отношении точек зрения друг друга. Вам удается создать мой мысленный образ сообщества .NET Core как неконструктивный и еще хуже. Поговорим о восприятии ...

Большая часть материалов, не относящихся к NuGet, будет объединена с csproj. Что будет с материалами NuGet, если не будет project.json (nuget.json?)?

предоставить пользователям возможность управлять своими зависимостями так, как им нравится, и, возможно, предоставить dotnet nuget по умолчанию, поскольку NuGet прочно закрепился в сообществе .net.

но не стоит жестко связывать все компоненты ядра dotnet с этим единственным способом управления зависимостями ( dotnet restore не должно быть равно dotnet nuget restore ), для многих людей nuget - это только репозиторий пакетов, но не диспетчер зависимостей, у людей действительно есть другие варианты, которые они могут найти более продуктивными / подходящими для варианта использования «диспетчера зависимостей».

Сохраним ли мы IntelliSense для управления зависимостями? По сути, это одна из лучших демонстрационных функций, которые у нас есть для project.json.

вы можете перепрофилировать логику, я не считаю это большим делом, например, я захожу на nuget.org, ищу пакет и копирую идентификатор из URL-адреса, это эффективно.

Возможно, вы захотите также предоставить автозавершение оболочки, что вызовет у вас много восхищения от людей, использующих bash или zsh :

dotnet nuget add S[tab] предоставляет список завершения для идентификаторов проекта, начинающихся с S

наличие intellisense в файлах msbuild * proj тоже должно быть выполнимо, если вы хотите запечь там тег <NuGet> , но то же самое, не связывайте nuget со всей экосистемой, то есть <Package>NuGetPackageId</Package> shouldn ' t приравнивается к <NuGet>NuGetPackageId</NuGet> ИЛИ должен быть очень простой (и очень хорошо документированный и поддерживаемый) способ переопределить это.

Плагин Paket Visual Studio имеет автозаполнение на nuget, он работает, но все равно работает медленно, потому что я предполагаю, что для возврата ответа от nuget.org требуется некоторое время.

Сохраняем ли мы формат JSON для управления зависимостями? XML ужасен для подобных вещей (см. Maven). JSON намного проще представить эти зависимости.

Если вы ищете идеи для формата, вы можете посмотреть на paket.dependencies , в противном случае, я не думаю, что это имеет большое значение, редактирование project.json было примерно так же хорошо, как редактирование packages.config с точки зрения работы с NuGet, делайте все, что удобно для пользователей, которые выбирают NuGet в качестве диспетчера зависимостей пакетов (что не является 100% пользователей и не обязательно)

В качестве примечания: если вам все еще нужен файл lock , не могли бы вы сделать его доступным для чтения пользователем, что-то, что проверяется в репозитории, и что легко сделать различие?

@rhires С этого момента, что msbuild будет добавлять / вычитать / заменять в / из / в этом процессе?

Ну, это зависит от того, как они это интегрируют. Если они выполняют «жесткую блокировку», глубоко интегрируя msbuild в сборку dotnet, что, по-видимому, указывает на то, что общедоступная информация является их предпочтительным подходом, тогда он будет полностью заменен на msbuild.

Однако, если они сделают dotnet build настраиваемым, я ожидаю, что это будет работать примерно так:

  1. Собирает файлы проекта
  2. Читает project.json
  3. Определяет целевые фреймворки
  4. Определите инструмент сборки для использования
  5. Обратитесь к инструменту сборки
  6. Вывод отчетов

@neoKushan Вот почему все эти споры о том, что действительно делает сборка dotnet и для чего MSBuild хорош и для чего плох, абсолютно бессмысленны.

👍

Я хочу _discuss_, как должны выглядеть project.json и csproj в мире, где dotnet build может передавать MSBuild как один из _многих возможных инструментов сборки_. Все хорошо? Можем ли мы поговорить о том, что будет в project.json по сравнению с тем, что будет в csproj, учитывая это?

Потому что, если мы _можем_ это обсудить, я верю, что эта дискуссия действительно может стать конструктивной.

@jmm Вам

Извини за это. Однако, если у вас есть время, я бы посоветовал прочитать некоторые архивы чатов других крупных проектов с открытым исходным кодом.

Споры на самом деле являются признаком здорового сообщества, как и в жизни. Когда все слепо следует за лидерами, что ж, обычно дела обстоят не так хорошо. Решения, доказательства и принятие решений должны быть открыты для допроса.

@shederman В интересах продолжения продуктивного обсуждения я также хотел бы подвести черту, чтобы обсудить последствия предлагаемых изменений.

Я думаю, что основное обсуждение здесь должно быть на макете и формате «нового» .csproj и о том, что происходит с project.json (или, точнее, структурой «проекта» в целом). Я не думаю, что система сборки, будь то msbuild или нет, как работает сборка dotnet и т. Д., Находится в рамках _этой_ проблемы. Это не означает, что дискуссии по этому поводу нежелательны или недействительны, просто они не относятся к этой _ конкретной_ проблеме, скорее, они должны быть отдельными вопросами. Как может подтвердить любой опытный разработчик, очень неприятно, когда отчет об ошибке содержит несколько отдельных ошибок, и обычно первое, что вы делаете, - это разбиваете их на несколько проблем для отслеживания - я думаю, это действительно то, чего здесь не хватает.

С моей личной точки зрения, мне все равно, что такое система сборки и как она работает. Я не имею в виду, что это звучит невежественно или пренебрежительно по отношению к тем, кто это делает, я имею в виду, что с точки зрения разработчика, я просто хочу знать, что "dotnet build" выплевывает мою сборку, пока структура проекта верна - так что пока как я понимаю, dotnet build -> Project ->-> Сборка. Единственное, что действительно важно для меня, и каков должен быть объем этого обсуждения (и я думаю, что мы, наконец, пришли к согласию), - это то, как этот проект выглядит и что он означает для моего повседневного рабочего процесса.

Я не хочу иметь дело с адом слияния только потому, что я добавил файл .cs, и я не хочу иметь дело с файлом XML длиной в тысячу строк только потому, что от этого зависит какая-то система, которая _Мне не важна_ - я не Не думаю, что кто-то из нас так думает, и это уже много лет является проблемой разработки VS. У нас был проблеск надежды с форматом project.json в его нынешнем виде, потому что он был _ намного лучше_, чем то, что было раньше, поэтому я полностью понимаю и понимаю, почему настроение так быстро иссякло при простом намеке на то, что мы вернемся к "старые плохие времена", но в то же время стоит отметить, что мы не должны обманывать себя - сегодня project.json ни в коем случае не идеален, у него есть свой набор проблем, и хотя они могут быть незначительными по сравнению с проблемы "старого" csproj, стоит быть объективным и обсудить, что можно улучшить и что может быть лучше.

Есть определенно лучший вариант из обоих миров.

Я думаю, что основное обсуждение здесь должно быть на макете и формате «нового» .csproj и о том, что происходит с project.json (или, точнее, структурой «проекта» в целом).

Вы знаете, об этом несколько раз упоминалось в этой беседе, но я подумал, что упомяну об этом еще раз, просто чтобы поделиться своим «личным ага» сегодня утром, но сейчас предпринимаются совершенно другие усилия с системой проектов на основе Roslyn. - или, если быть более точным, из его readme Central Project System (CPS) . Просматривая его документацию, кажется, что это больше похоже на определение проекта, чем на процесс. Может быть, именно здесь объединяется вся магия между .json и .csproj? И тогда MSBuild станет конечной точкой процесса? Было бы неплохо. :улыбка:

В любом случае, я начал / смотрел это репо, чтобы начать получать обновления о том, что там происходит. : +1:

(Я также наполовину задаюсь вопросом, стоит ли нам перенести это обсуждение в новый вопрос.)

@neoKushan Определенно, факт наличия msbuild сам по себе не является проблемой. И я думаю, что есть путь вперед, который позволит нам сохранить простые удобочитаемые / редактируемые форматы файлов, используя при этом мощь msbuild.

Что меня беспокоит, так это аргументы типа «msbuild протестирован в боевых условиях», обычный msbuild есть, а текущий xplat, похоже, нет. Когда мы смотрим на проблемы в соответствующем репозитории github, его еще нет. Кроме того, команда msbuild уже заявила, что поддержка нового / улучшенного формата сериализации не будет целью для msbuild, а скорее для новой системы сборки (что не произойдет в ближайшее время).

Меня также беспокоит, когда люди предполагают, что мы просто добавляем и удаляем зависимости. Может быть, это то, что они делают, потому что просто создают приложения «привет, мир». Но другие параметры, такие как buildOptions и переопределения по прозвищу, чрезвычайно эффективны и удобны. Не говоря уже о том, что текущий опыт редактора на основе схемы json просто потрясающий.

Один из путей может заключаться в наличии задачи msbuild, которая в качестве альтернативы загружает project.json. Затем позвольте разработчику выбрать в настройках проекта, если он хочет включить project.json, который добавит эту задачу в csproj.

@ Mike-EEE Да, есть надежда :)

Я почти уверен, что в настоящее время мы склоняемся к тому, чтобы project.json превратился в nuget.json, что, надеюсь, решит проблему зависимости и оставит большую часть существующих функций project.json в действии.

Единственное, что я не могу понять, - это как это влияет на мультитаргетинг, должны ли csproj и nuget.json знать и понимать, на что они нацелены? Получим ли мы csproj для каждой цели (фу!), Или они могут расширить .csproj в достаточной степени, чтобы это учесть?

project.json становится nuget.json

Просто любопытно ... где происходит _это_ разговор? Раньше я входил в команду nuget для привязки к определенному формату. Что касается project.json, они сказали, что это проблема инструментария Visual Studio, которую они не могут решить. Теперь кажется, что динамика изменилась и скопировано / вставлено больше проблем того же типа. : stuck_out_tongue:

Чтобы прояснить мою озабоченность, сейчас мы смешиваем вместе JSON и XML, что, по крайней мере, приводит к неэффективности.

Просто любопытно вот ... где идет этот разговор?

Ну, это было изначально указано здесь: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

Возможно, останется файл project.json, содержащий все ссылки на пакеты для NuGet, и он будет переименован в nuget.json.

И я думаю, что это действительно то, о чем идет речь: сколько вы вынимаете из project.json и вкладываете в .csproj? В моих проектах большая часть project.json была ссылками на пакеты, особенно если я нацелен на несколько фреймворков. Вышесказанное предполагает, что все это останется, и будут удалены только «другие» биты. По моему (опять же: личному) опыту, эти "другие" биты действительно не сильно меняются в течение жизни проекта, поэтому даже если они в XML, это не много XML, и он должен быть довольно статичным ... можно надеяться .

Я согласен с тем, что смешивание и сопоставление XML и JSON для разных конфигураций немного неприятно, но тогда я несколько предвзято отношусь к JSON, поскольку я не большой поклонник того, как он используется. Однако это определенно личное предпочтение.

Ну, это было изначально заявлено здесь ...

Ах да ... конечно! В ПОРЯДКЕ. Просто убеждаюсь. Надеюсь, завтра мы наконец получим некоторую ясность (к лучшему или к худшему!) По этому поводу.

Я согласен с тем, что смешивание и сопоставление XML и JSON для разных конфигураций немного неприятно

Очень рад, что я не единственный, кто это видит и так чувствует. :) Некоторое время мне там казалось одиноко, когда я впервые боролся с горем, увидев, что .JSON проникает в проекты. Полностью имеет смысл с точки зрения фона разработки веб-приложений, но родной appdev не нравится, и наоборот, когда дело доходит до XML.

Ха-ха ... кстати говоря, написание вышеизложенного заставило меня вытащить старые архивы. Вот я еще в 2014 году приводил доводы в пользу (да, вы уже догадались!) Xaml вместо JSON, хахаха, о, посмотрите, каким молодым и совершенно наивным я был! Такой милый и непритязательный! Боже, мне нужно было изучить мир. : stuck_out_tongue: Но я скажу, что был НЕКОТОРЫЙ прогресс. В конце концов,

@neoKushan Есть определенно лучшее из обоих миров.

👯 👯 👯

@neoKushan Я почти уверен, что текущая тенденция состоит в том, чтобы project.json превратился в nuget.json ... Единственное, что я не могу понять, это как это влияет на мультитаргетинг, должны ли csproj и nuget.json знать и понять, на что они нацелены?

Используя схему project.json в качестве отправной точки, с моей точки зрения, следующие элементы, вероятно, _не_ должны быть в файле определения сборки:

  • Список исходных файлов
  • Зависимости проекта
  • Целевые рамки
  • Команды проекта (например, веб, тест и т. Д.)
  • Webroot
  • Метаданные
  • Языковая версия

Следующее, что я не верю_, должно быть в файле определения сборки, но я бы _meh_ об этом сказал бы, если бы они были:

  • Определения конфигурации
  • Скрипты, до и после

Следующее, вероятно, _ должно_ быть в файле определения сборки:

  • Варианты компиляции (кроме языковой версии)

Сказанное выше просто для того, чтобы спровоцировать дискуссию. Рад обсудить любые отдельные моменты. Предложите пока не обращать внимания на то, как называются файлы и какой у них формат.

@shederman Нам нужно прояснить, что вы подразумеваете под "определением сборки"? Возможно, моя терминология отключена, но я бы не стал называть текущий project.json файлом _build definition_, а скорее файлом _project definition_ (и то же самое относится к новому файлу csproj). Возможно, семантика, но для меня определение сборки предполагает, что оно определяет _как устроены вещи_, тогда как определение проекта определяет, что составляет проект, и оставляет шаги сборки чему-то другому.

_Это мой проект, он состоит из этих элементов и имеет эти зависимости. Как вы его построите - не мое дело.

Большая часть проекта может быть определена просто по соглашению, например, как имя сборки происходит из папки верхнего уровня. Следуя этой линии мышления, _nuget.json_ будет иметь какое-то отношение к nuget - поэтому туда войдут пакеты / зависимости, и я думаю, что мы все довольны этим.

Я не могу определиться с целевыми фреймворками. Если Nuget.json занимается только разрешением зависимостей, то, хотя он может иметь некоторое разделение для ссылок при нацеливании на разные фреймворки, я не совсем уверен, что он должен решать, какие фреймворки на самом деле нацелены, что кажется чем-то большим для _project определение_ (что бы это ни было).

Опять же, nuget - это нечто большее, чем просто ссылки на пакеты, он также содержит пакет _definition_ и версию, а также, когда ваша библиотека _ становится_ пакетом nuget. Кажется, что тогда nuget.json выполняет как минимум две разные вещи, и это начинает немного пахнуть. Возможно (здесь просто наплевать) csproj будет определять детали пакета, целевые платформы и т. Д., И каждая целевая структура может указывать на файл .json, который в основном является пакетами nuget. Другими словами, вместо одного nuget.json у вас будет отдельный файл .json для каждой платформы. Это может быть ужасная идея, я не особо обдумал ее.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

У нас было два варианта. Один из них заключался в переводе всех проектов .NET на использование project.json. Это потребует от нас работы с инструментами, которая затрагивает все типы проектов в Visual Studio, Xamarin и наших партнерах, таких как Unity. Нам нужно будет расширить project.json, чтобы поддержать все сценарии сборки, необходимые для каждого из этих типов проектов, и предоставить историю миграции. Другой вариант - построить мосты, чтобы проект .xproj мог ссылаться на проект .csproj, а проект .csproj мог ссылаться на проект .xproj в Visual Studio и Xamarin Studio. У моста также есть проблемы, например, когда заказчик создает проект, ему теперь нужно выбрать .xproj или .csproj, что просто добавляет больше возможностей и сложности.

И

После рассмотрения нашего выбора стало очевидно, что было бы проще перенести проекты .NET Core в .csproj / MSBuild, чтобы все проекты .NET использовали одни и те же инструменты и систему сборки.

Мы планируем улучшить .csproj для поддержки недостающих функций:

  • Нет списка файлов в системе проектов
  • Инструмент CLI для выполнения любых операций с файлом проекта, для большинства сценариев вы не будете редактировать файл
  • Сборка пакетов прямо из проекта
  • Мульти-таргетинг

А поскольку весь .NET использует одни и те же инструменты, мы можем рассмотреть возможность улучшения MSBuild. Мы будем запрашивать отзывы от клиентов и сообщества о поддержке JSON вместо XML, о том, что наши инструменты не будут генерировать слишком подробные файлы и многое другое. А поскольку все использует одни и те же инструменты, эти улучшения могут работать во всех проектах .NET.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

Предполагая, что .csproj по-прежнему означает проект C #, конечно, будут и другие цели для проектов, отличных от C #, верно? [Бен]

да. [Скотт Х.]

Я немного боюсь, что .net застрянет с системой сборки complex-legacy-justForTooling как msbuild, может быть, нам стоит начать с нее, чтобы запустить dotNetCore, а затем спланировать новую современную систему сборки?
Чтобы дать каждому надежду и сделать что-либо без спешки с выпуском .netcore.

Мне не часто нужно редактировать файлы msbuild, но когда мне это нужно, это очень сложно, декларативный подход заставляет вас теряться в потоке, я привожу свой пример, похоже, никто не может решить простую проблему, подобную этой https: // github .com / madskristensen / BundlerMinifier / issues / 89.
Если по прошествии 6 месяцев никто не мог запустить задачу (две разные задачи, каждая из которых не знает о другой) за другой без грязных взломов или аддитивным способом, возможно, там есть что исправить.

Спасибо

Инструмент CLI для выполнения любых операций с файлом проекта, для большинства сценариев вы не будете редактировать файл

: -1:

Я сторонник инструментов CLI, которые помогут вам выполнять вашу работу, но если мне _придется_ использовать инструмент CLI для управления ссылками и пакетами, я расстроюсь. Install-package - это здорово, но возможность просто набрать половину имени пакета и получить всплывающий список возможностей со всеми их версиями - это было потрясающе.

Инструменты cli отлично подходят для автоматизации, но не подходят для выполнения задач, за исключением базовых, таких как npm install или dotnet restore . Если нам нужно выучить такие вещи, как dotnet buildoptions define add --framework net451 SOME_DEFINE это определенно отстой. Это огромная потеря.

Хорошая история разработки:

  • Легко редактируемые файлы проекта и сборки
  • Настраиваемая система сборки
  • Простые, хорошо продуманные и полные инструменты cli
  • Отличный графический интерфейс, инструменты IDE

Делать одного из этих бедных (что было действительно здорово раньше), чтобы сделать другого приемлемым, просто глупо.

Аргумент единства и xamarin на самом деле довольно плох. Я не думаю, что они так скоро перейдут на ядро ​​.net, а возвращаться назад для их удобства - это просто неудача при проектировании для будущего .net.

И поскольку весь .NET использует одни и те же инструменты, мы можем рассмотреть возможность улучшения MSBuild.

Никакой MSBuild не будет улучшен, пока мы не будем вынуждены его использовать ...

Эта статья на самом деле не тот пост в блоге, которого мы ждали, и она подтверждает, что ядро ​​.net вводится в заблуждение.

Инструменты cli отлично подходят для автоматизации, но это плохой способ выполнять задачи, за исключением базовых, таких как установка npm или восстановление dotnet.

Опять же, я считаю, что эта проблема - столкновение культур / предпочтений / философии. Где-то по пути CLI стал хорошей идеей для замены GUI, когда на самом деле вам нужны оба, поскольку вы обнаружите, что разработчики (снова) имеют свои предпочтения в подходе. В этой области, безусловно, требуются некоторые инновации, поскольку кажется, что это постоянно является проблемой: интерфейс командной строки создается, а графический интерфейс - нет, и наоборот.

Мне кажется, что для создания API требуется некоторая структура, а затем версии CLI и GUI создаются автоматически для вас.

Мы могли бы назвать это ... CLIGUIAPI! : +1:: +1:: +1: # проблемы решены

этот вопрос - столкновение культур / предпочтений / философии

Определенно, и это одна из тех проблем, которые вы не можете решить, за исключением рассмотрения каждого подхода наилучшим возможным подходом. node.js и я не самый большой поклонник этого стека, отлично справился с этим, имея отличный инструмент cli npm и package.json. Часть Gui адресована различными поставщиками (webstorm, vs code, visual studio). Необычные системы сборки, такие как gulp, на сто процентов необязательны.

возможно, я меньшинство в этом, а может и нет, но хотя мне нравится project.json, причины объяснены здесь https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json / имеет для меня большой смысл. Я совершенно уверен, что в конечном итоге у нас будет хороший опыт, поэтому я действительно не беспокоюсь об этом, и это никоим образом не умаляет моего энтузиазма по поводу этих новых фреймворков. Кажется, что люди очень быстро выбирают вилки и ведут себя так, будто наступил конец света, даже не видя, каким будет финальный опыт.

Я перестал читать какое-то время назад, но закрою этот вопрос, как только у нас будет окончательный ответ по поводу project.json .

Как насчет сохранения и project.json, и .csproj, где .csproj генерируется командой dotnet restore и по умолчанию не синхронизируется в системе контроля версий? Разница будет в том, что вместо dotnet restore генерации «project.lock.json» (и других действий) он будет генерировать (или обновлять) файл «.csproj». Могут остаться даже файлы «project.lock.json» и «.csproj», поскольку они создаются автоматически. Флаги можно использовать в dotnet restore для создания .csproj. В объявлении Microsoft уже говорит: «Инструмент командной строки для выполнения любых операций с файлом проекта, в большинстве сценариев вы не будете редактировать файл». IMHO, dotnet restore больше всего подходит для ЭТОГО инструмента CLI, который будет принимать project.json в качестве входных данных. Плюсы будут-

  • Оба формата project.json и .csproj могут оставаться неизменными. Это означает, что новый сгенерированный .csproj будет совместим с более ранними версиями Visual Studio и другими инструментами. dotnet restore может вставить явный "включаемый" список файлов проекта в файл .csproj.
  • Поскольку .csproj создается автоматически и не находится в системе контроля версий, разработчикам не нужно заниматься ручным редактированием и объединением .csproj.

yeahno

Ага ... нет.

Закрытие. Все, что можно было сказать, было сказано.

Если вы хотите придумать, как это должно быть сделано, и быть в команде дизайнеров, которая об этом говорит ... пожалуйста, сделайте это .

В противном случае это бесполезная трата места и особенно ... заполнение почтовых ящиков.

@MaximRouiller надеется, что вы

@neoKushan Нам нужно прояснить, что вы подразумеваете под "определением сборки"? Возможно, моя терминология отключена, но я бы не стал называть текущий project.json файлом определения сборки, а скорее файлом определения проекта (и то же самое относится к новому файлу csproj). Возможно, семантика, но для меня определение сборки предполагает, что оно определяет способ построения, тогда как определение проекта определяет, что составляет проект, и оставляет шаги сборки чему-то другому.

В значительной степени в моих мыслях. Определение проекта будет чисто декларативным описанием того, что представляет собой проект. Метаданные, версии, спецификации файлов и т. Д. Определение сборки - это шаги, которые выполняются для преобразования проекта в исполняемый код. Для определения сборки почти наверняка потребуется что-то довольно богатое, из которых мне больше всего нравится код.

Но все это кажется спорным: @MaximRouiller и MS закрыли все. Ваш отзыв был проигнорирован и уничтожен, спасибо за звонок.

В целом, вся вещь csproj -> project.json -> csproj была набором плохих решений, которые вернутся, чтобы преследовать MS при принятии .NET IMHO. Тенденция отказа разработчиков от .NET в пользу более зеленых пастбищ будет продолжаться.

image

Так грустно.

@shederman Нет никакой корреляции между снижением индекса Tiobe для C # и решением вернуться к csproj. Кроме того, снижение индекса Tiobe не является признаком ухудшения состояния экосистемы C #. Все больше языков, выходящих на рынок, затрудняет удержание какой-либо одной из них значительной доли рынка.

Everything is awesome

Я не совсем понимаю влияние в целом, но я хотел бы отметить, что здесь должна быть оценка с разделением проблем. Если csproj означает, что мои товарищи по команде обеспокоены другими воздействиями, связанными с процессом сборки, просто потому, что я добавляю файл, то мы упускаем из виду лодку.

csproj - это то, что я терплю, а не предпочитаю.

@jerometerry Я не говорил, что это само по себе вызовет спад. Но многие инновационные изменения в .NET Core были нацелены на то, чтобы остановить спад и убытки AWS. Эти изменения постепенно удаляются одно за другим, и поэтому .NET Core становится все более и более маловероятным, чтобы привлечь разработчиков к платформе.

Кроме того, плохое принятие решений, которое можно проследить вплоть до решения ввести project.json до сегодняшнего дня, не сулит ничего хорошего.

Если РС настроены сосредоточиться на прошлом, им не следует удивляться, когда они проиграют в будущем. Мышление, которое привело вас к проблеме, вряд ли поможет вам ее решить.

Все больше языков, выходящих на рынок, затрудняет удержание какой-либо одной из них значительной доли рынка.

Верно, но по моему опыту больше вреда, чем необходимо в .NET, наносит дружественный огонь.

Кстати ... там вчера был стендап? Я вошел в live.asp.net, но обратный отсчет просто сбросился, без видео / фида или чего-то еще ...

@ Mike-EEE Они слышали, что ты идешь: stuck_out_tongue_winking_eye:

Обидно, что они это сделали. Я писал об этом в блоге: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

Из сегодняшнего стендапа: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

Он конкретно обращается к project.json здесь: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Хотя формат project.json намного проще редактировать (если только вы не находитесь на той стадии разработки .NET, которая превращается в обезьяну с перетаскиванием набора данных), самая большая проблема для меня в том, что никто не пытается обновить свои библиотеки до. netcore. Пока мне удалось заставить работать одну ветку Restsharp, но она использует формат project.json. JSON.NET, Structuremap, NUnit и т. Д. И т. Д. Имеют устаревшие ветки DNX, и похоже, что разработчики оставили надежду.

Поэтому немного странно называть .NET Core RC1 / 2 кандидатом на выпуск, когда из проекта удаляется инструмент командной строки dotnet . Для меня это все еще бета-версия или даже альфа-версия, поскольку она экспериментальная.

Моя основная мотивация для перехода на vNext - это использование дешевого хостинга Linux и Docker. Инструмент миграции проекта как можно скорее будет разумным, поскольку большинство людей будут полностью ограничены своими библиотеками из-за ссылок на nuget, в которых отсутствуют версии .NET Core.

@yetanotherchris dnx был концепцией в rc1, он был изменен на dotnet cli в rc2, поэтому большинство проектов или веток dnx в это время будут устаревшими

project.json все еще здесь и необходим для rc2, обсуждение этого вопроса исчезнет в будущем после RTM

json.net aka newtonsoft.json действительно работает и используется самим фреймворком, я тоже использую его в своих проектах
нунит не совместим, все используют xunit afaik
Structuremap имеет и rc2-совместимую библиотеку

есть еще много сторонних вещей, которые еще не портированы на rc2, но Microsoft не контролирует сроки других проектов и когда они сделают совместимые библиотеки

@yetanotherchris Если вы используете импорт в своем project.json, вы можете указать старые, нестандартные прозвища, и он будет их использовать:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

Вероятно, по этой причине не так много людей позаботились об обновлении своих библиотек, нет необходимости поражать другую движущуюся цель до фактической RTM.

@joeaudette Я говорил об имени ветки (DNX), а не об инструменте командной строки dotnet . Многие люди используют NUnit, это в значительной степени набор для тестирования де-факто за пределами MsTest. Я не уверен , где вы найти пакеты Json.NET или StructureMap из, есть неофициальная версия StructureMap называется DNX и ветвь Newtonsoft здесь и .NET Standard 1.0 бета на nuget.org (.net стандарт теперь избыточно насколько я знаю).

@neoKushan, спасибо, я разберусь.

Я думаю, что моя главная мысль заключалась в том, что было бы немного глупо называть его релиз-кандидатом, поскольку он полностью изменится в финальной версии. Может быть, через месяц мы получим ажиотаж, поскольку системы сборки не совсем отличаются от старых и новых - хотя как человек, который в первую очередь является веб-разработчиком, я бы предпочел project.json .

@yetanotherchris

(Насколько я знаю, стандарт .net теперь избыточен).

что заставляет тебя говорить это? Netstandard не уйдет с изменением проекта, он останется. Вы сможете настроить таргетинг на netstandards в ваших будущих файлах csproj. Netstandard абсолютно необходим. Одна из основных причин, по которой они отказываются от project.json, - это унификация всей экосистемы .net, и это то, что netstandard также предлагает.

Я думаю, что моя главная мысль заключалась в том, что было бы немного глупо называть его релиз-кандидатом, поскольку он полностью изменится в финальной версии.

Я в какой-то мере согласен с этим, хотя не думаю, что это изменится так сильно, как думают люди. Для начала, project.json по-прежнему будет здесь для RTM, все изменения произойдут после этого. Затем вы можете спросить, зачем называть его «Final», если он собирается измениться, и, возможно, в этом есть смысл, но в конечном итоге весь ваш код, библиотеки и все, что не меняется, это просто проект _definition_. Это не такое уж большое изменение, как можно было бы подумать изначально, хотя определенно будет некоторая забавная миграция.

@yetanotherchris, вы должны помнить, что rc2 - это предварительный просмотр, поэтому вам также нужно искать пакеты предварительного просмотра от сторонних производителей.
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

Я не знаю о NUnit, будет ли он поддерживаться позже, но пока в проектах .NET Core и ASP.NET Core люди используют xunit.
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris Я думаю, мы все можем согласиться с тем, что rc1 должен был быть помечен как beta9, rc2 - это первый настоящий качественный релиз rc
project.json и подобные инструменты не являются частью фреймворка как такового, инструменты будут оставаться в предварительном просмотре и могут быть изменены в течение некоторого времени, даже если фреймворк является RTM.

Я даже не удивлюсь, если мы вообще вернемся - возможно, мы сохраним project.json, и он работает только в ограниченных сценариях. Если люди этого хотят, мы поддержим эту идею.

Скотт Хантер, dotnetConf 2016 ,

Кто-нибудь знает, есть ли мистер Хантер на GitHub? И следить за болтовней на товарных форумах? Судя по всему, здесь он упускает из виду обратную связь.

Как менеджер программ для .NET и Visual Studio, я сомневаюсь, что у @coolcsh есть свободное время.

Я был бы в ужасе, если бы он не узнал о полученных комментариях. Может быть, не все подробности, но, безусловно, есть существенный откат.

Вот ваш шанс всем:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

Я положил доллар в банку для чаевых, так сказать. : stuck_out_tongue:

tugberkugurlu, возможно, что-то понял из-за комментария «внезапно, корпоративные разработчики темной материи начали давать обратную связь за закрытыми дверями». Можно было бы сказать иначе: «наши корпоративные клиенты выразили серьезную озабоченность по поводу совместимости и своих текущих инвестиций в наши продукты». Хотя «сообщество», похоже, недовольно тем, что ему не принадлежит львиная доля права голоса, ну, ну, корпоративные клиенты несут довольно большую палку: они платят большие деньги за доступ к платформам, инструментам и поддержке. Их опасения нельзя игнорировать, да и не следует им игнорировать. В конце концов, MS, похоже, стремится к тому, чтобы позволить максимальному количеству разработчиков легко создавать то, что они хотят построить, и они также хотят попытаться обеспечить совместимость и совместное использование практически в каждом определяемом домене. Они обещают упростить работу с csproj и сделать его более функциональным. Итак, теперь они готовы к этому.

Как я уже много раз говорил, я корпоративный разработчик в крупном банке, корпоративный заказчик. С НАМИ не консультировались по поводу этих изменений. Так КТО именно были «корпоративными разработчиками темной материи»? Эта информация, по-видимому, является совершенно секретной. 007 уровень вещи.

Утверждать, что у корпоративных клиентов есть большая палка, - это хорошо и хорошо, но очевидно, что это могут сделать лишь НЕКОТОРЫЕ из них. Какие? По каким критериям? Как мы попали в этот список привилегированных? Какой это партнерский уровень? Какие годовые траты? Пытливые умы хотят знать, сколько ИМЕННО нам нужно платить РС, прежде чем они на самом деле прислушаются к нашему мнению?

@shederman вы корпоративный мобильный разработчик или корпоративный разработчик UWP? Или Enterprise Unity Dev?

Ни один из вышеперечисленных. Мы пишем базовые системы для управления активами и банковской интеграции. Некоторые онлайн-материалы тоже.

@shederman Я подозреваю, что может быть поэтому вас не спросили?

Просьба уточнить?

Вы действительно утверждаете, что единственные корпоративные разработчики, которых сейчас поддерживает MS, - это те, кто выполняет мобильную работу для 1% рынка, приложения UWP для гм, 5% небезразличных пользователей и разрабатывают игры? Из всего спектра разработки MS отворачивается от всего, кроме этого ?

Умм. Нет.

Я говорю, что изменения произошли после разговора с _сими_ группами, поэтому вас и не спросили. Microsoft должна поддерживать всех своих разработчиков, а не только разработчиков asp.

Да, поэтому, если они собираются поддерживать всех своих разработчиков, может быть, им стоит поговорить со всеми разработчиками. Возможно, просто поговорить с выбранной группой 5% корпоративных разработчиков - не лучший способ оценить мнение корпоративных разработчиков в целом.

Итак, чтобы к мнению крупного банка прислушались, мы должны перевести всю нашу разработку на UWP / Unity / Mobile?

Это просто смешно.

может им стоит поговорить со всеми разработчиками.

Разве это не то, чем они занимались последние 2+ года?

@shederman Значит, только потому, что _ вас лично_ не спросили, вы подразумеваете, что никто другой, кто охватывает ваш диапазон разработки, не участвовал?

Кроме того, хватит придумывать эти числа - это смешно.

@poke Я спрашиваю, кто был замешан? Я говорю, что слышал, как с разработчиками корпоративной темной материи консультировались, и указывал, что я в банке, а мы нет, так кто именно?

Я действительно думал, что цифры были довольно щедрыми, но ладно.

@shederman Я думаю, ты слишком много буквально просили годы . Достаточно посмотреть вокруг, чтобы увидеть, что многие люди хотели большего от ядра .NET.

Существует также вопрос о реальных запросах на корпоративную поддержку от крупных организаций, желающих узнать, как перенести свои существующие данные на кроссплатформенность - вас, вероятно, не спросили, потому что вы не требовали, чтобы кто-то из Microsoft сказал вам, что то, что вы пытаетесь сделать, выходит за рамки проекта.

Другой способ взглянуть на это - и то, как я лично это вижу - это то, что вас спросили, вас спросили во второй раз, когда было сделано объявление несколько месяцев назад. Несмотря на все крики людей о том, что решения были приняты без консультации с кем-либо, Microsoft неоднократно заявляла, что они все еще прорабатывают детали, что у них еще нет окончательных частей, и теперь пришло время высказать свое мнение . Скотт Хантер даже сказал, что если люди действительно_ хотят использовать project.json в качестве опции, они рассмотрят возможность его сохранения. Если вы мне не верите, посмотрите доклад dotnetconf.

@neoKushan Я ценю, что Скотт немного отступил, сказав, что они

project.json был хорошим шагом. Но на мой взгляд это было наивно. При этом не учитывается, что люди хотели бы иметь гибридные проекты, написанные на C ++ или F #. Некоторые из их ранних дизайнерских решений, такие как dnx и использование nuget в качестве единицы сборки, были неприменимы для экосистемы dotnet в целом. Вы видите, что в процессе достижения гармонии в dotnet они должны сделать этот трудный выбор.

На мой взгляд, форк и переизобретения не помогут экосистеме дотнетов, а только повредят ей. Node и Go (особенно Go) очень привлекательны для новичков, потому что у них однородная и согласованная платформа / инструменты.

Я считаю, что весь аргумент XML против JSON глуп, потому что еще через 5 лет это будет JSON против YAML, а после этого YAML против Groovy (например, gradle). XML не такой злой, как вы все представляете. MSBuild очень развит, и в него вложено много средств, которые принесут пользу всем.

Тем не менее, много работы должно быть сделано с MSBuild , чтобы убедиться , что вы можете получить одинаковые или по крайней мере менее болезненный способ использования и редактирования csproj файлов. Затем переместите зависимости nuget в файл nuget.json. Используйте Соглашение вместо Конфигурации, чтобы, если вы находитесь на «счастливом пути», ваш csproj будет почти пустым, немного похожим на web.config сегодня. а затем есть параметры cli, которые настраивают csproj

Что касается меня, я буду скучать по project.json, но не по тем причинам, по которым вы думаете ... Проекты C # подойдут. Я буду скучать по нему из-за F #. Я предпочел редактировать project.json для порядка компиляции, а не редактировать msbuild. Опять же, не потому, что xml - это зло, а потому, что файлы fsproj сильно раздуваются, вызванные msbuild.

Моя проблема с этим решением заключалась прежде всего в том, что файл csproj был меньше о xml / json и гораздо больше о том, что они решили включить в файл csproj. Он содержал определение проекта, он содержал настройки IDE, он содержал шаги сборки, он содержал ссылки ...

Не так уж много того, что _не__ попало в это дело. Это сделало его ужасным и усугублялось только тогда, когда приходилось иметь дело с msbuild, который временами был довольно загадочным. Если вы искренне заинтересованы в том, чтобы .NET Core был хорошим, а не просто работал, сделайте файл проекта независимым от инструментов сборки. Я должен иметь возможность указать, что это за проект и от чего он зависит, отдельно от того, как его построить. Не говоря уже о том, что это позволяет нам выбирать инструменты, даже если исходный вариант прямо сейчас поддерживается msbuild.

Я согласен с этим. В конце концов, ключевой проблемой csproj является то, что
он все делает.

Мне нравится золотая середина, которую предлагает Патриот Боб ...

Во вторник, 21 июня 2016 г., в 13:28 PatriotBob [email protected] написал:

Моя проблема с этим решением заключалась в первую очередь в том, что файл csproj был меньше
о xml / json и многое другое о том, что они решили включить в csproj
файл. Он содержал определение проекта, он содержал настройки IDE, он
содержит шаги сборки, он содержит ссылки ...

Не так уж много того, что _не__ попало в это дело. Это сделало это
ужасно и усугубляется только тогда, когда приходится иметь дело с msbuild, являющимся
временами довольно загадочно. Если вы честно заинтересованы в том, чтобы .NET Core был хорош
И не просто работа делает файл проекта независимым от инструментов сборки. Я должен
уметь указать, что это за проект и от чего он зависит отдельно от
как его построить. Не говоря уже о том, что это позволяет нам выбирать
инструментарий, даже если исходный вариант только что поддерживается msbuild прямо сейчас.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911 или отключить звук
нить
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

XML в целом плох, JSON - отличная шумиха, сильно раздутая. Мне нравится то, что говорит Патриот Бобо.

управление проектом as / w полностью из npm package.json еще никогда не было так просто и лаконично: объявление моего проекта, построение моего проекта, обновление моего проекта (например, greenkeeper), чтение / запись / анализ данных о моем проекте, и опубликовать мой проект так легко. _так легко. как и многие из нас, моя история находится в c ++ / java / python / node, с игрой в других. Я хочу получить npm опыта во всех моих проектах сейчас.

project.json обещал обладать такими же характеристиками. Я считаю, что эту модель стоит подражать, а не жертвовать простотой и мощностью.

Если основная команда команды .net считает, что другое решение может предоставить им эти черты - отлично и мощно! однако, пожалуйста, не умаляйте красоты в простоте по мере вашего продвижения.

Кроме того, я понимаю, что к этому моменту я просто шумел в гигантском потоке. может быть, модераторам стоит подумать о том, чтобы закрыть его и справиться с суровым испытанием более контролируемым образом. много хороших отзывов. может быть, и немного троллинга: $ :)

Была ли эта страница полезной?
0 / 5 - 0 рейтинги