Aspnetcore: Сборки удаляются из Microsoft.AspNetCore.App 3.0

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

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

Большой! Когда я использую ядро ​​asp.net, мне просто нужно то, что мне нужно.

@davidfowl

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

По тем же причинам, по которым вы не включаете пакеты, перечисленные в верхней части этой проблемы. Я просто думаю, что всегда легче добавить больше пакетов в платформу, которая будет поставляться с .NET Core 3.0, чем удалять пакеты позже. Почему бы вам не начать добавлять наименьший общий знаменатель для запуска обычного приложения ASP.NET Core, а затем предлагать остальное в виде пакетов NuGet. Если это окажется проблемой для разработчиков, вы всегда можете добавить что-то позже, но вы больше не сможете удалить вещи позже так же легко.

Потому что мы также должны соблюдать баланс, чтобы быть полезными по умолчанию.

Хорошо, я думаю, что ванильный ASP.NET Core уже полезен (и я думал, что вы тоже так думаете, иначе почему вы не сделали его полезным?), Но если вы уже решили, что должно быть во фреймворке и что не тогда забудь;)

Если бы вы были пуристом, у вас не было бы большей части промежуточного программного обеспечения, MVC или SignalR в комплекте, потому что они не являются строго необходимыми. Проведение этой границы между тем, что должно быть по умолчанию, а что нет, - это в значительной степени интуитивное ощущение и нечеткая вещь (основанная на опыте, просмотре других платформ в прошлом и настоящем и совершении звонка). Что касается ASP.NET Core 3.0, у нас нет планов отказываться от них (по крайней мере, прямо сейчас).

Да, я знаю, что это всегда сложно сделать, но иногда я не уверен, каково оправдание тенденции (со стороны Microsoft) раздувать вещи больше, чем это необходимо. То, как вы позиционируете свою продукцию на рынке, будет восприниматься вами. Предполагается, что ASP.NET Core будет новой современной компонуемой и гибкой веб-структурой, но то, как вы все позиционируете, таково, что ASP.NET Core бесполезен, если вы не навязываете MVC + SignalR + Identity + EF всем. На мой взгляд, вы уже указали, где должны быть нарисованы линии, поэтому MVC и SignalR не встроены в ASP.NET Core, а являются отдельными фреймворками, которые могут быть добавлены при желании, так почему вы сейчас размываете эти линии? Это кажется непоследовательным, и я не могу придумать, какую ценность вы получите от этого. Вместо того, чтобы просто продвигать ASP.NET Core + процветающую экосистему с открытым исходным кодом, вы продвигаете очень узкий веб-интерфейс. Все это вызывает разочарование у тех, кто хочет немного отличаться и больше работать для себя, поскольку вы в конечном итоге навязываете людям вещи, которые им, возможно, не нужны.

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

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

PS: Не уверен, что это так, но я надеюсь, что SignalR также является отдельным пакетом NuGet. Это как если бы вы включили Bootstrap и Angular2 в свой фреймворк по умолчанию. Если бы эти два продукта были разработаны Microsoft, вы, вероятно, сделали бы это, но это не имело бы смысла, и я думаю, только потому, что они созданы третьей стороной, вы понимаете, как это не имеет смысла.

TBH Я бы хотел, чтобы из установки по умолчанию было удалено больше вещей. Особенно MVC. Это то, что делает альтернативные платформы поверх ASP.NET Core еще более привлекательными. Также мне интересно, почему такие вещи, как ContentResult, живут в MVC, а не в ядре. Он часто используется в функциях Azure, и теперь мне всегда приходится ссылаться на материалы MVC - только для ContentResult.

Я думаю, дело в том, что наличие MVC в ASPNET SDK не должно отрицательно повлиять на вас. Большинство разработчиков будут использовать его, поэтому такой способ доставки предпочтительнее чрезмерного восстановления. Если не хочешь, можешь просто не использовать. Большинство пакетов, перечисленных выше, содержат сторонние зависимости (json), имеют некоторые серьезные аспекты (бритва) или концептуально отделены от ASPNET и часто упоминаются вне SDK (EFCore).

Насколько я согласен с установлением минимальных значений по умолчанию для создания равных условий для OSS-фреймворков, это должно быть сбалансировано. На заре разработки ядра (бета-версии и даже 1.0) пакеты были повсюду, и это было НАМНОГО более запутанным, и восстановление длилось вечно.

@psibernetic, даже если материал находится в отдельных пакетах, установщик ядра .net может поместить эти пакеты уже в локальные кеши.

@psibernetic Вы второй, кто упоминает, что баланс важен, но что это вообще значит? Баланс между чем? Не будем говорить о крайностях, потому что это явно нехорошо, давайте поговорим здесь о реальных предложениях. Если MVC представляет собой отдельный пакет NuGet, каким образом это влияет на удобство использования? На самом деле это не так, и это моя точка зрения. Думать, что вы собираетесь решить одну крайность, реализовав противоположную крайность, - это узкое мышление. Между ними много чего. Фреймворк не должен быть раздутым, а MVC и SignalR также не должны быть фрагментированы на 100 пакетов. И того, и другого можно избежать одновременно.

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

И разговор о времени восстановления ...

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

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

Я думаю, что это нежелательное вредоносное ПО для всех других пользователей, которые не используют MVC, например CandyCrush, предварительно установленную на моем ПК с Windows 10. Ядро Asp.net проповедовало, что оно становится менее самоуверенным с полностью настраиваемым, по мере необходимости промежуточным программным обеспечением и т. Д. Шаблоны dotnet позволяют MVC быть включенным пакетом по умолчанию без необходимости его включения в ядро?

Есть много других фреймворков, таких как Nancy, ServiceStack и Giraffe, которые имеют свои достоинства и не должны иметь раздувания / конфликтов с нежелательной / ненужной принудительной установкой MVC. Это просто кажется непоследовательным, учитывая, что аутентификация, бритва, EF и т. Д. Все упакованы, но MVC, золотой ребенок должен быть частью базовой структуры, когда он не является ядром?

Если это из-за того, что MVC настолько тесно связан с ядром, что развязка потребовала бы тонны работы, я могу это понять, но на основе этого, как правило, облегчает жизнь некоторых разработчиков, кажется ленивым и очень похожим на старый asp.net Менталитет MVC, от которого я надеялся, мы уклонились.

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

Я имею в виду, что я заставляю команду ASP.NET полагать, что они создают лучшую структуру, на которую могут, но не все согласны со всеми выбранными мнениями или уровнем сложности, необходимым для выполнения чего-либо. Все в .NET Core было разработано с учетом преимуществ ретроспективного анализа, во многом основанного на том, какие подходы стали успешными на других платформах, путем запекания мнений о том, какие технологии использовать, и вам не хватает следующих инноваций, исходящих от .NET и даже когда следующая вещь действительно наберет обороты на других платформах, ASP.NET Core окажется в невыгодном положении, чтобы повторить ее успех, поскольку мы будем постоянно платить «налог на MVC» по умолчанию, когда ожидается, что все будут использовать его модель разработки для всего Интернета. Приложения до бесконечности.

Легкость Node также делает его подходящим для разработки ряда других сценариев использования, таких как Electron, Native Mobile Apps, IOT, сценарии оболочки и т. Д., Т.е. ни один из них не выигрывает от наличия веб-фреймворка, связанного с установкой по умолчанию. Чем более раздутой становится установка по умолчанию, тем менее полезной она становится для использования в других сценариях.

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

Спасибо за ваш отзыв! Позвольте мне поделиться некоторыми мыслями.

1. Мы не обрезаем сборки, потому что нам просто так хочется. Каждая удаляемая нами сборка является критическим изменением и увеличивает стоимость обновления с 2.x до 3.0. Это руководящие принципы, которые мы используем, чтобы решить, что входит в Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. В сборках, которые мы предлагаем удалить, отсутствуют некоторые критерии для включения в общую структуру. Примечательно, что эти сборки либо: (1) имеют зависимости от стороннего кода, который мы не можем обслуживать (2) сами сборки устарели в версии 3.0, либо (3) они реализуют протоколы или механизм аутентификации, которые очень подвержены изменениям ( например, Facebook / Google / Twitter могут завтра решить изменить способ работы аутентификации)

2. Мы не будем рассматривать удаление MVC из Microsoft.AspNetCore.App. Хотя мы признаем, что не каждый пользователь ссылается на MVC в своем приложении, мы считаем, что это центральная часть предложения ASP.NET Core. Мы планируем сохранить это в Microsoft.AspNetCore.App.

3. MVC был частью Microsoft.AspNetCore.App с версии 2.1, но, как вы увидите в шаблонах «Пустой веб» 2.1 , вам не обязательно использовать MVC. Его присутствие в общей структуре не заставляет вас использовать его в своем приложении. Вы по-прежнему можете использовать альтернативы, написать свою собственную структуру представления или использовать более «сырые» API-интерфейсы aspnetcore для прямого чтения и записи HTTP-запросов и ответов.

4. @dustinmoris : Я просто думаю, что всегда проще добавить больше пакетов в платформу, которая будет поставляться с .NET Core 3.0, чем удалять пакеты позже. Почему бы вам не начать добавлять наименьший общий знаменатель для запуска обычного приложения ASP.NET Core, а затем предлагать остальное в виде пакетов NuGet. Если это окажется проблемой для разработчиков, вы всегда можете добавить что-то позже, но вы больше не сможете удалить вещи позже так же легко.

   Это именно то, что мы пытаемся сделать. Легче добавить, чем удалить. Мы добавили слишком много вещей в 2.0 и снова приспосабливаемся к тому, что, по нашему мнению, является поддерживаемым набором вещей в обозримом будущем. Большинство сборок, удаленных из Microsoft.AspNetCore.App, по-прежнему будут предлагаться в виде пакетов NuGet. Если бы мы позже обнаружили, что 90% всех клиентов ссылаются на один и тот же пакет, это хороший кандидат для общей платформы. Однако, как упоминалось в руководстве , степень использования API является важной метрикой, но не единственным фактором, который мы принимаем во внимание.

5. «Ваниль» - это субъективно. Для многих наших пользователей MVC и SignalR являются «ванильными».

6. Некоторые люди говорили, что .NET Core должен был быть тем или иным, или еще чем-то. Вещи меняются, мы собираем отзывы пользователей, наблюдаем за тем, как используется продукт, и пытаемся изменить настройки по умолчанию, чтобы они соответствовали тому, что, по нашему мнению, принесет пользу наибольшему количеству клиентов. Предлагаемые в этом выпуске корректировки отражают отзывы, полученные нами о .NET Core 2.x.

Заключительная мысль: эта проблема не всех обрадует. Если вам кажется, что мы игнорируем ваш отзыв, прошу прощения. Примите во внимание, что у нас сотни тысяч клиентов, и лишь небольшая часть из них приходит на GitHub, чтобы поделиться отзывами. Мы также собираем информацию из личных посещений, телефонных звонков, электронных писем, социальных сетей, запросов в службу поддержки, блогов, телеметрии Visual Studio и т. Д. Все это является частью того, что мы принимаем во внимание при принятии решений, и что является частью стандартного опыта, а что нет.

Если что-то неясно в наших мотивах или причинах, дайте мне знать, и я постараюсь уточнить.

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

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

Все это говорит, и имейте в виду, что я не связан с Microsoft или командой aspnet, я МОГ УВИДИТЬ, как поставлялась отдельная среда выполнения, которая представляла собой barebones aspnetcore, ЕСЛИ сообщество действительно озвучивало это и доказывало, что это большая потребность. Миссия состоит в том, чтобы предоставить отличный опыт как можно большему количеству приложений и разработчиков, и на данный момент невероятно высокий процент тех, кто извлекает выгоду из MVC в общей среде выполнения. @natemcmaster есть ли предпочтительный способ для заинтересованных лиц проголосовать за это в будущем, возможно, проблема GitHub, и является ли это разумным решением?

@psibernetic, вы можете начать новую проблему GitHub для удаления MVC из общей платформы, но, как я уже сказал выше, удаление MVC из Microsoft.AspNetCore.App - это не то, что мы будем рассматривать, поэтому эта проблема вряд ли получит поддержку в Наша команда.

@Bomret Практически каждое реальное клиентское приложение, которое мы проверили, тем или

@Natemcmaster : Я сейчас
понял, что речь идет о метапакете, когда я говорил о
общая структура.

@natemcmaster Я думаю, что @forki , @dustinmorris , @gerardtoconnor и @mythz указали очень веские причины, против которых я еще не слышал контраргументов. Было бы очень хорошо иметь базовую веб-среду выполнения / библиотеку, которую авторы фреймворка могли бы построить поверх, например, nodejs, вместо того, чтобы связывать с ней самоуверенные вещи. Как уже упоминалось ранее, node настолько успешен, потому что он не требует слишком много, но предоставляет хорошие абстракции, которые вы можете построить поверх. MVC не исчезнет, ​​он просто уйдет и станет выбором среди множества других веб-библиотек и фреймворков. Включая его, вы занимаетесь этим. Конечно, большинство разработчиков просто принимают его в том виде, в котором он поставляется вместе со средой выполнения, вместо того, чтобы смотреть дальше. По моему честному мнению, это звучит как политика и маркетинг - без обид.

Он называется «Microsoft.AspNetCore.App», почему бы не создать второй «Microsoft.AspNetCoreMVC.App»?

В любом случае, я понимаю, что очень сложно провести черту, но я думаю, что общий отзыв здесь заключается в том, что у вас, ребята, растет число людей, которым нравится то, что вы сделали с ядром aspnet, но которым не очень нравятся такие вещи, как MVC, razor , EF или signalR.

Действительно. Вы можете рассчитывать на то, что сообщество будет достаточно активным, чтобы предложить множество идей для библиотек и фреймворков для обработки api, Интернета, веб-сокетов, шаблонов, доступа к базе данных и т. Д. Вы, ребята, предоставили бы один вариант для тех, у кого есть MVC, Razor, EF и т. Д., Но только не единственный и не по умолчанию.

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

@natemcmaster Не могли бы вы быстро подтвердить, правильно ли я все понял:

• В следующую среду выполнения .NET Core (3.0) будет встроена общая платформа ASP.NET Core, что означает, что ASP.NET Core будет поставляться как часть установки .NET Core в среде.

• Кроме того, есть метапакеты Microsoft.AspNetCore.App и Microsoft.AspNetCore.All которые представляют собой набор пакетов NuGet для приложений ASP.NET Core.

• Общая платформа ASP.NET Core <метапакет Microsoft.AspNetCore.App , который включает такие вещи, как EF Core?

• Я могу создать веб-приложение ASP.NET Core без необходимости включать мета-пакет Microsoft.AspNetCore.App , который содержит EF Core, SignalR, MVC и т. Д., Если я просто хочу создать чрезвычайно крошечный API?

• Что бы вы, ребята, ни делали, можно будет создать контейнер Docker только с минимальными зависимостями для ASP.NET Core, чтобы запускать крошечный API?

В следующую среду выполнения .NET Core (3.0) будет встроена общая платформа ASP.NET Core, что означает, что ASP.NET Core будет поставляться как часть установки .NET Core в среде.

да

Кроме того, существует метапакет Microsoft.AspNetCore.App и Microsoft.AspNetCore.All, который представляет собой набор пакетов NuGet для приложений ASP.NET Core.

Нет. Есть новая концепция под названием FrameworkReference и Microsoft.AspNetCore.App будет одной из них. Microsoft.AspNetCore.All не будет существовать в версии 3.0.

Общая платформа ASP.NET Core <метапакет Microsoft.AspNetCore.App, который включает такие вещи, как EF Core?

Нет, он не включает EF.

Что бы вы, ребята, ни делали, можно будет создать контейнер Docker только с минимальными зависимостями для ASP.NET Core, чтобы запускать крошечный API?

С обрезкой сборки и компоновщиком - да, а не путем удаления пакетов, потому что их не будет для ASP.NET Core.

@natemcmaster

Мы не обрезаем сборки, потому что нам просто так хочется. Каждая удаляемая нами сборка является критическим изменением и увеличивает стоимость обновления с 2.x до 3.0.

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

Мы не будем рассматривать удаление MVC из Microsoft.AspNetCore.App. Хотя мы понимаем, что не каждый пользователь ссылается на MVC в своем приложении.

Он называется «Microsoft.AspNetCore.App», что логически читается как «ссылка на этот пакет», если вы создаете «приложение ASP.NET Core».

мы считаем, что это центральная часть предложения ASP.NET Core. Мы планируем сохранить это в Microsoft.AspNetCore.App.

Это приближается к сути проблемы, когда кажется, что цели ASP.NET Core отходят от создания простой и открытой экосистемы в стиле node.js. Все ли хотят объединить приложения ASP.NET Core как синонимы приложений MVC? Некоторыми преимуществами ASP.NET Core были «плати за игру» и разделенная «многоуровневая структура», но это говорит о том, что «приложение ASP.NET Core» навсегда предназначено для = приложения MVC.

Для всех участников было бы яснее, если бы в пакетах было более четко указано, где:

• Microsoft.AspNetCore.App => База для всех приложений ASP.NET Core
• Microsoft.AspNetCore.Mvc => Приложение ASP.NET Core MVC

Но если Microsoft.AspNetCore.App неприкасаем, могли бы мы, по крайней мере, иметь официальный мета-пакет «базовой линии» (или FrameworkReference) только с основными функциями сервера (то есть без каких-либо самоуверенных библиотек), с некоторыми потенциальными именами:

• Microsoft.AspNetCore. [База | Голый | Lite | Базовый]

(«Ядро» тоже было бы подходящим, но этот термин уже используется слишком часто).

Без официального метапакета / имени он не будет таким доступным, как рекомендуемый в настоящее время «Microsoft.AspNetCore.App», который является рекомендуемой основой для всех приложений ASP.NET Core.

Ограничения порождают инновации, где, если бы MVC мог работать только на том же игровом поле, что и все остальные, возможно, у всех нас был бы доступ к функции, которая позволяет нам легко и явно объявлять, какие продукты (также называемые набором пакетов) нужны приложениям, например, это могло бы что-то выглядеть нравиться:

• Microsoft.AspNetCore.Mvc + SignalR + EF

Где каждый может легко объявить и установить только то, что ему нужно, а инструменты за кулисами могут объединить метапакеты «Microsoft.AspNetCore.Mvc», «Microsoft.AspNetCore.SignalR» и «Microsoft.AspNetCore.EF». (Или альтернативное решение для достижения цели).

Его присутствие в общей структуре не заставляет вас использовать его в своем приложении.

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

Вы по-прежнему можете использовать альтернативы, написать свой собственный фреймворк,

Это не так приятно, как вы думаете, например, когда мы разрабатывали нашу собственную «структуру представления», альтернативную MVC и Razor, мы столкнулись с волшебным поведением в .NET Core, когда сборка завершалась ошибкой при запуске стандартной команды для публикации файла. NET Core, то есть:

 dotnet publish -c Release

Что не получится с:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

Удивительное поведение, учитывая, что мы разрабатывали альтернативу MVC, которая явно не ссылалась на MVC, Razor и не включала какие-либо страницы .cshtml поскольку ее целью было создание приложений без их использования.

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

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Что позволило опубликовать проект. Во время испытаний различных переключателей для исправления неработающей сборки мы также обнаружили, что можем уменьшить опубликованный объем на 150 .dll в /refs/*.dll , отказавшись от метаданных, которые излишне раздували наше веб-приложение .NET Core 2.0 на отказ от метаданных, необходимых для Razor, с помощью:

<PreserveCompilationContext>false</PreserveCompilationContext>

Таким образом, в основном вынуждены играть в удар, чтобы выяснить, какие переключатели нам нужны, чтобы сообщить инструментам, что мы не используем MVC, чтобы не допустить, чтобы он нарушал сборки проекта и выводил ненужные метаданные, которые нужны только приложениям MVC / Razor. Было бы гораздо предпочтительнее начать с «базового» пакета метаданных, где такие проблемы были бы невозможны, поскольку инструментальные средства не могли предполагать, что каждое приложение использует MVC, потому что биты MVC не существуют.

Хотя легко сказать, что ASP.NET Core по-прежнему является благоприятной платформой, которая поощряет эксперименты, создание и использование альтернативных «фреймворков представления», объединение предписанных самоуверенных веб-фреймворков, таких как MVC, - это едва ли не самый враждебный шаг, который можно было бы сделать, чтобы воспрепятствовать созданию и использование указанных альтернатив. Выделите момент, чтобы взглянуть на количество появляющихся популярных альтернатив, и это хороший показатель, чтобы увидеть, насколько привлекательна для них платформа.

Если предполагается, что каждое приложение ASP.NET Core должно включать MVC, чем любая другая альтернативная «структура представления» (включая один файл .cs добавляемый в методы ext), будет казаться более «тяжелым» "и громоздко, чем использование связанного MVC, поскольку все они должны быть связаны с ним + все остальное, что необходимо фреймворку представления.

Таким образом, было бы предпочтительнее, если бы "MVC" был включен и не был включен в пакет .App , но если решение необратимо, можем ли мы иметь хотя бы официальную базовую базу метапакетов, которая не не включать это?

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

ИМО, спрос на не раздутый стартовый пакет недостаточно представлен, анекдот: из всех шаблонов проектов C # /. NET, которые мы создали для VS 2012, VS 2013, VS 2015, VS 2017 и .NET Core, неизменно самого популярного шаблона безусловно, всегда был «Пустой» шаблон, который также был частой критикой классического ASP.NET за то, что пустой шаблон ASP.NET по умолчанию VS.NET не был достаточно пустым. Это было тогда, когда вы могли создать «пустой» классический ASP.NET .NET Framework без MVC, но теперь в более новой, легкой и более модульной платформе ASP.NET Core MVC входит в минимальный рекомендуемый стартовый пакет.

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

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

По моему опыту, проще рассуждать о явном, чем о раздутых фреймворках с магическим поведением. Если это явно, вы можете взаимодействовать с ним, искать его, читать о нем, удалять его, тестировать запуск без его использования (чтобы узнать, является ли это причиной проблем), и это видно при сравнении проектов с разными конфигурациями. Но с волшебным поведением инструментов MVC, нарушающих сборки моего проекта mvc / razor-less выше, я понятия не имел, какая часть моего проекта запускает его, почему он даже работает, как отключить или как решить эту проблему. Я все еще не уверен, что мои проекты, не использующие MVC, не замедляются из-за того, что MVC объединен, или что он генерирует неоптимальный вывод, потому что он должен соответствовать MVC или Razor.

Телеметрия Visual Studio и многое другое.

Будет сложно сравнивать телеметрию популярности базового метапакета, которого не существует, если бы он сделал ИМО, у него было бы более чем достаточно популярности, чтобы заслужить его включение. Ранее «Microsoft.AspNetCore.All» нацелен на другой конец спектра и включал вселенную, но не более полезную инверсию минимальной полезной базовой линии.

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

@Bomret

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

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

Я думаю, вы здесь немного неверно истолковываете общую структуру. Вам просто нужно рассматривать его как своего рода стандартную библиотеку, поставляемую с .NET Core. Чтобы сделать ссылку на Node: представьте, что текущая версия Express была связана с Node. Вам не нужно _не_ использовать его, но он уже есть, когда вы хотите его использовать.

Что касается MVC, я считаю, что вы не совсем понимаете, что MVC на самом деле включает в ASP.NET Core. Если вы не хотите использовать контроллеры и представления Razor, хорошо, но вы, вероятно, все равно будете использовать довольно много функций MVC в своем приложении.

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

Как что?

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

Да, пожалуйста, скажите, выглядит немного покровительственным, большинство из нас задействовано в альтернативных фреймворках, построенных на основном промежуточном программном обеспечении / пустельге, поэтому у нас есть достойное представление о том, что мы используем, контроллеры и представления Razor - это небольшое подмножество MVC, мы знаю это. Фреймворки F #, Giraffe / Saturn и Zebra, работают лучше, чем MVC, с лучшей маршрутизацией и упрощенной моделью обработки. При рендеринге Zebra x2 быстрее, чем MVC на TechEmpower, поэтому мы предпочитаем не использовать его по умолчанию. если сборка-обрезка / компоновщик может уменьшить занимаемую площадь позже, то это, по крайней мере, кое-что, но было бы идеально, если бы он не был включен по умолчанию, чтобы обеспечить более равномерное игровое поле для других фреймворков, получить максимальную отдачу от базовой платформы asp.net.

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

Я могу указать только на @mythz, чтобы проиллюстрировать суть дела. Чем больше взаимосвязано, тем больше они запутываются. Я имею в виду Ват !? MVC влияет на сборку приложения Asp, даже если вы нигде не ссылаетесь на него ?!

@poke
Как уже писали другие: это не так. Это сборка вещей, не имеющих ничего общего с базовой средой выполнения. Представьте, что экспресс-фреймворк по умолчанию был бы связан с node, вы думаете, что экосистема стала бы такой яркой и разнообразной?

Я также совершенно не понимаю, как удаление MVC, SingalR и т. Д. Из базовой установки и предоставление их в виде одного пакета NuGet можно обозначить как «дополнительную сложность». В любом случае разработчики в любом случае устанавливают дополнительные пакеты. И если предоставление их в качестве дополнительных упаковок приведет к «значительному» увеличению времени восстановления, они в любом случае слишком толстые.

@Tratcher

Однако любое подразделение

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

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

Чтобы прояснить, как это читается: требуется слишком много инженерных затрат, чтобы удалить ненужные накладные расходы из каждого приложения ASP.NET Core, которое не использует MVC, потому что, если бы MVC работал как любая другая альтернативная структура, это значительно усложнило бы «MVC».

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

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

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

Что ж, этого следовало ожидать, в ущерб любой другой альтернативе это предписанная структура, включенная в минимальную рекомендуемую установку по умолчанию, например, Apple дает всем бесплатную песню U2, нравится она им или нет.

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

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

Выиграют ли разработчики из-за дополнительной путаницы и нечеткого определения того, что такое «приложение ASP.NET Core»? «Раньше это было похоже на node.js для .NET, но теперь это больше похоже на самоуверенный фреймворк одного поставщика, где практически каждое приложение начинается с кучи самоуверенных вещей, которые предписывают, как вы должны создавать веб-приложения, вы можете думать об этом как о любом Приложение предустановлено с помощью Express и его зависимостей по умолчанию - вы должны его использовать "

Выигрывают ли разработчики из-за особого корпуса MVC? Он не устанавливается и не обновляется, как что-либо еще, и полагается на скрытые инструменты и магическое поведение, которое вам нужно поискать, чтобы узнать, существует и отключить. Такой специальный корпус добавляет случайную сложность, когда рассуждая о своем проекте, вы должны поддерживать другой набор правил того, как работает MVC, и как работает все остальное.

Если бы он был явным, это улучшило бы читаемость, и вы могли бы сказать из конфигурации проекта, что это приложение MVC, например:

• Microsoft.AspNetCore.Mvc

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

Сохраняя его в проекте по умолчанию «Microsoft.AspNetCore.App», вы навсегда связываете его с каждым приложением ASP.NET Core и делаете его невыгодным для чего-либо лучшего. Веб-страницы ASP.NET были еще одной платформой представлений Razor, добавленной в ASP.NET несколько лет назад, которая была установлена, а также по умолчанию была включена агрессивная магия. Он поставлялся со своей собственной IDE веб-матрицы, которая больше не поддерживается и не доступна для загрузки, поэтому у нас остался случай, когда сложность мертвой технологии навсегда встроена в классический ASP.NET и активно вызывает проблемы для других активных веб-платформ. привязка к использованию страниц Razor .cshtml которые навсегда должны носить с собой багаж, приведенный ниже, чтобы явно не допустить, чтобы веб-страницы нарушали свои рамки представления:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

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

1. Измените «Microsoft.AspNetCore.App» на минимальную полезную базовую планку для всех приложений ASP.NET Core (т. Е. Без MVC).
2. Поддерживайте метапакет, такой как «Microsoft.AspNetCore.Base», который каждый, не использующий MVC, может использовать в качестве минимально полезной базовой линии.

Если ни один из них не будет рассматриваться, можем ли мы иметь хотя бы флаг всего проекта, например mvc:enabled = false который все инструменты MVC могли бы проверять, чтобы отключить и предотвратить их запуск?

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

Если ни один из них не будет рассматриваться, можем ли мы иметь хотя бы флаг для всего проекта, например mvc: enabled = false, который все инструменты MVC могли бы проверять, чтобы отключить и предотвратить их запуск?

Не могли бы вы уточнить, какие функции инструментов вы бы хотели отключить? Возможно, это стоит отдельного разговора.

@Tratcher

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

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

Не могли бы вы уточнить, какие функции инструментов вы бы хотели отключить? Возможно, это стоит отдельного разговора.

Две проблемы, с которыми я столкнулся, заключались в необходимости вручную настроить /p:MvcRazorCompileOnPublish=false что препятствовало публикации моего проекта (без страниц .cshtml). Другой флаг, который следует отключить:

<PreserveCompilationContext>false</PreserveCompilationContext>

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

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

@mythz, давай, опубликуй эту проблему.

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

@davidfowl Звучит довольно

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

@davidfowl Минимальный базовый пакет будет полезен для всех приложений, отличных от MVC - например, будет много других легких приложений и микросервисов, которые захотят обойти все фреймворки и писать непосредственно в ответ. ИМО, эта опция должна быть доступна в коробке, мы бы предпочли не начинать с неофициальной базы, состоящей из версий пакетов, которые мы не контролируем. В идеале все должно быть добавлено из базового пакета вместо того, чтобы начинать с другого касательного, поддерживаемого извне. Но, возможно, это одна из областей, где внешнее сообщество может объединиться, чтобы поддержать базовое подмножество «AspNetCore», которое полезно для всех приложений и платформ, отличных от MVC.

С учетом сказанного, где нам следует искать, чтобы создать собственный фреймворк? Возможно, это будет так же просто, как начать с копии того, что использовалось для создания «Microsoft.AspNetCore.App», и удалить все несущественные библиотеки, чтобы вернуть его к минимальному полезному подмножеству.

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

@natemcmaster Может помочь с подробностями о том, как создать собственный общий фреймворк.

@davidfowl, вы предложили создать собственный, я только после того, как смог начать с минимальной полезной базы без самоуверенных фреймворков. Мы не хотим ссылаться на несколько пакетов по отдельности по той же причине, по которой всем приложениям ASP.NET Core рекомендуется ссылаться на «Microsoft.AspNetCore.App» - это более доступно, если иметь возможность ссылаться на один пакет.

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

Здесь все, кажется, единодушны в том, что MVC не входит в базовый пакет. Единственный другой «продукт», который, похоже, включен, - это SignalR, который, как я полагаю, будет менее использоваться, чем MVC, и меньше причин для включения. Я не очень хорошо знаком с тем, что находится в каждом пакете, но все остальное кажется в целом полезным и благоприятной частью «платформы» ASP.NET Core.

Хорошо, позвольте мне высказать предложение, чтобы попытаться быть конструктивным здесь. Мы не меняем Microsoft.AspNetCore.App, мы думаем, что это то, что понадобится большинству пользователей, и они будут его использовать. Давайте представим еще один уровень, который представляет собой эту «базовую» общую структуру (изначально мы сделали что-то подобное с https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). Это общий фреймворк, на котором вы бы построили эти другие фреймворки (например, Nancy и ServiceStack).

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

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

Да, я думаю, что это ближе к тому, чтобы содержать много необходимого для настройки приложения и его запуска и работы. Из приложений Microsoft.AspNetCore.App мы также используем:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Так что такие вещи, как HTTP, хостинг, ведение журнала и абстракции конфигурации (полезные для большинства HTTP-приложений), также было бы неплохо включить, а также все остальное, что кто-то сочтет подходящим. Мое единственное предпочтение - не включать MVC / SignalR.

и теперь становится интересно. как уже сказал Давид: у людей разные
идеи о том, что означает «ядро». С моей точки зрения, я не думаю, что DependencyInjection
должно быть в. / пожимание плечами

Am Do., 8. ноя 2018 гм 08:30 Uhr schrieb Demis Bellot <
[email protected]>:

Да, я думаю, это ближе к тому, чтобы вместить в себя много необходимого для
настройка и запуск приложения. Из глубины в
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App мы также
с использованием:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Такие вещи, как HTTP, хостинг, ведение журнала и абстракции конфигурации
(полезно для большинства HTTP-приложений) тоже неплохо было бы включить
еще кто-нибудь сочтет нужным. Мое единственное предпочтение - не иметь
MVC / SignalR включены.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz Большинство из них включены транзитивно.

@forki 😆 Добро пожаловать в наш мир.

Мы не меняем Microsoft.AspNetCore.App, мы думаем, что это то, что понадобится большинству пользователей, и они будут его использовать.

Знаменитые последние слова. Это оправдание любого плохого решения - «МЫ думаем, что ОНИ нуждаются в этом».

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

Иногда полезно послушать опытных пользователей.

В любом случае мы не собираемся менять Microsoft.AspNetCore.App. Я предложил компромисс, который, как мне кажется, удовлетворяет здесь требованиям.

@forki, если вы используете ядро ​​aspnet, вы все равно сталкиваетесь с DI, лучше включить в него удобные методы по умолчанию (Get service, GetRequiredServiceи лайки в этом пакете). И, привет, F # даже не может создать их самостоятельно из-за отсутствия ограничения T:> U https://github.com/fsharp/fslang-suggestions/issues/255, так что ¯_ (ツ) _ / ¯

Я хотел бы упомянуть эту базовую общую структуру @davidfowl ... Я думаю, что @mythz и @dustinmorris подойдут для такого подхода. Это также подходит для Saturn @ Krzysztof-Cieslak

вы все равно сталкиваетесь с DI

Я знаю, и мы обсуждали это несколько раз. Просто я бы предпочел не
;-) Но что есть, то есть...

Утренний пт, 9 ноября 2018 г., 10:57 hat Нино Флорис [email protected]
geschrieben:

@forki https://github.com/forki, если вы используете ядро ​​aspnet, вы
так или иначе столкнувшись с DI, лучше включить в него удобные методы
по умолчанию (Get service, GetRequiredService и т.п. находятся в этом
упаковка). И, эй, F # даже не может создавать их самостоятельно из-за отсутствия
T:> U-ограничение fsharp / fslang-questions # 255
https://github.com/fsharp/fslang-suggestions/issues/255 так что ¯_ (ツ) _ / ¯

Я хотел бы иметь эту базовую общую структуру @davidfowl
https://github.com/davidfowl упомянул ... Я думаю, @mythz
https://github.com/mythz и @dustinmorris
https://github.com/dustinmorris подойдет и для такого подхода.
Это также подходит для Saturn @ Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Обновлен исходный пост, чтобы включить:

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

Они выводятся из общей платформы и будут поставляться в виде пакетов NuGet. Эти сборки зависят от API-интерфейсов IdentityModel, которые еще не соответствуют рекомендациям для общей платформы. Мы начали работать с командой IdentityModel и планируем вернуть их в общую структуру в будущем. cref https://github.com/aspnet/AspNetCore/pull/6035

Обновите исходное сообщение, включив в него Microsoft.AspNet.WebApi.Client. См. Https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

Я часто достаточно запутался, так как это то, что мне нужно включить.

Говоря о Visual Studio - должен ли я открыть узел Microsoft.AspNetCore.App и сделать перекрестную ссылку на все, что находится под ним, с тем, что я мог установить индивидуально?

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

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

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

Суть в том, что можно улучшить координацию работы с командой Visual Studio, чтобы убедиться, что IDE просто немного умнее, понимая эти мегапакеты и сообщая мне, что что-то безопасно удалить, а затем в версии 3 сообщая мне, что мне нужно это добавить обратно ;-)

@simeyla благодарит за отзыв. То, что вы говорите, связано с темой, но это не совсем то, о чем идет речь. Инструменты для оптимизации ссылок на пакеты станут новой функцией Visual Studio. Эта функция может быть в целом полезной не только для этого сценария, поэтому я предлагаю отправить этот отзыв непосредственно в Visual Studio. В VS используйте «Справка> Отправить отзыв ...». Если вы поделитесь ссылкой после того, как создадите сообщение, я могу перенаправить ее внутри наших коллег, которые работают над VS.

В версии 3.0 мы полностью удалим метапакет Microsoft.AspNetCore.App и внесем множество изменений в пакеты, которые мы отправляем. Мы начали документировать, как выполнить обновление с 2.x до 3.0, и продолжим обновлять этот документ по мере завершения списка сборок, поставляемых в версии 3.0.

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

В список добавлен Microsoft.Extensions.DependencyModel . Изменено как часть https://github.com/aspnet/AspNetCore/pull/10271

Вопрос здесь @natemcmaster @DamianEdwards , есть упоминание о шаблонах, имеющих все необходимое для локальной сборки. Означает ли это, что с этой мыслью и удалением библиотек аутентификации любой шаблон аутентификации не будет работать в автономном режиме в версии 3.0? Я понимаю, что ни одна библиотека аутентификации не будет работать в автономном режиме, но если у меня нет кеша nuget, я теоретически мог бы получить сбой сборки после создания нового шаблона аутентификации, если бы я был в автономном режиме. Это похоже на плохой опыт.

Да, это один из результатов этого изменения. Начиная с Preview 6 (скоро), dotnet new mvc , dotnet new razor , dotnet new web и другие не имеют никаких PackageReferences, поэтому они не должны быть затронуты, но с указанием дополнительных параметров , например --auth individual может привести к присутствию PackageReference, что требует загрузки пакета.

Здесь мы идем на преднамеренный компромисс. Хотя шаблоны, которые имеют PackageReference, не будут восстанавливаться в автономном режиме на чистой машине, мы также избегаем многих проблем, возникающих при попытке создать предварительно заполненный автономный кеш NuGet (для начала, проверьте https://github.com/dotnet/ dotnet-docker / issues / 237, https://github.com/NuGet/Home/issues/6309 и http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster полностью понимает, и я понимаю рассуждения, просто нужно хорошо задокументировать, иначе после первоначальной версии 3.0 dotnet new webapp --auth Individual не строится.

Может ли кто-нибудь рассказать мне, почему Microsoft.AspNetCore.Authentication.JwtBearer скомпилирован с зависимостью от .netcoreapp3.0? А может не на .netstandard2.x? Я хочу использовать его в библиотеке классов, и мне нравится, чтобы все мои classlibs были .netstandard

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie Я думаю, что эту проблему стоит <PackageReference> чтобы компенсировать API, который был перемещен из Microsoft.AspNetCore.App.

@Bomret Практически каждое реальное клиентское приложение, которое мы проверили, тем или

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

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

Нам нужно переместить этот список в документы

@davidfowl добавлено: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-links

@pranavkm этот список на самом деле является полной противоположностью: вещи, которые больше не являются пакетами, но, вероятно, все еще находятся в общей структуре.

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

@scottaddie - это список, на который нам нужно сослаться в документации по созданию библиотеки ASP.NET Core.

@DamianEdwards это - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-ссылки-для-удаленного -сборки?

Это тот самый :)

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

a) Кажется, что теперь, если есть улучшение компонента AspNetCore (скажем, SignalR), то нам нужно дождаться выпуска нового «пакета dotnet» для Microsoft.AspNetCore.App, чтобы использовать его, взяв с собой все еще в этом паке?
б) Больше не может создавать служебные классы для AspNetCore в библиотеках классов netstandard (например, промежуточное ПО Auth). Теперь библиотеки классов должны быть netcoreapp3.0 для размещения этого материала. Это означает разделение наших библиотек служебных классов на реализации netstandard / netcore.
РЕДАКТИРОВАТЬ: c) Как мне на самом деле определить, какую версию пакета я использую, если я сделаю <Project Sdk="Microsoft.NET.Sdk.Web"> ? Очевидно, мы хотим иметь воспроизводимые сборки в разных ветвях после обновления dotnet.

a) Кажется, что теперь, если есть улучшение компонента AspNetCore (скажем, SignalR), то нам нужно дождаться выпуска нового «пакета dotnet» для Microsoft.AspNetCore.App, чтобы использовать его, взяв с собой все еще в этом паке?

SignalR поставляется по тому же графику, что и остальная часть AspNetCore, поэтому здесь нет изменений в расписании.

SignalR поставляется по тому же графику, что и остальная часть AspNetCore, поэтому здесь нет изменений в расписании.

Так это просто плохой пример? Можно ли то же самое сказать обо всех других удаленных пакетах NuGet?

SignalR поставляется по тому же графику, что и остальная часть AspNetCore, поэтому здесь нет изменений в расписании.

Так это просто плохой пример? Можно ли то же самое сказать обо всех других удаленных пакетах NuGet?

Я так думаю. Все компоненты .NET Core и ASP.NET Core используют один и тот же график поставки. Если чего-то не произошло, его пришлось бы отправить в отдельной упаковке.

Я так думаю. Все компоненты .NET Core и ASP.NET Core используют один и тот же график поставки. Если чего-то не произошло, его пришлось бы отправить в отдельной упаковке.

Поверю тебе на слово. У меня нет конкретных встречных примеров. При обновлении пакетов AspNetCore NuGet в прошлом этого просто не было.