Aspnetcore: Обсуждение: ASP.NET Core 3.0 будет работать только на .NET Core

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

Тем не менее, мне грустно по поводу последствий для некоторых компонентов ASP.NET Core, которые в настоящее время могут существовать как отдельные зависимости. Поскольку это, вероятно, будет означать, что отдельные компоненты откажутся от поддержки netstandard, вместо этого потребуется netcoreapp3.0; и особенно с # 3756 эти компоненты были бы непригодны для использования вне контекста ASP.NET Core.

Например, такие проекты, как RazorLight, будут фактически вынуждены отказаться от .NET Framework и, что более важно, от поддержки .NET Standard в целом.

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

Я не уверен, какую аналитику вы использовали для обоснования этого шага, но для запуска приложений ServiceStack ASP.NET Core на платформе .NET Framework мы видим, что самый популярный шаблон web-corefx для запуска проекта ASP.NET Core на платформе .NET Framework составляет более 1/3 (33,8%) доли того же пустого веб- шаблона, который является нашим самым популярным шаблоном проекта для работы в .NET Core.

ИМО 3 года - недостаточно времени, чтобы отказаться от клиентов, которые начали или перешли на новую модель программирования ASP.NET (чтобы избежать застойной платформы ASP.NET Framework), только чтобы теперь узнать, что платформа, которую они продали в их организацию, чтобы переехать, было заброшено.

По какой-то причине есть клиенты, которые не могут перейти на .NET Core из-за того, что полагаются только на зависимости .NET Framework, если MS не хочет поддерживать поддержку .NET Framework в ASP.NET Core 3.0 в будущем IMO, вам следует расширить поддержку для ASP.NET Core 2.1 на .NET Framework на длительный период, например 7 лет. Миграция существующих производственных систем может занять годы, так как с момента запуска .NET Core стало ясно, что ASP.NET Framework осталась без изменений с официальной позицией, заключающейся в том, что ASP.NET Core - это будущая модель программирования для .NET, теперь те же клиенты скоро начнут обнаруживать, что новая модель программирования, к которой они перешли / переходят, не будет поддерживаться через несколько лет. Наилучший способ удовлетворить потребности существующих клиентов .NET - это поддерживать .NET 2.1 в течение дополнительного периода LTS, по крайней мере, для исправлений безопасности (в идеале также для устранения ошибок).

«Убивая .NET Framework», серия 2: та же история, те же персонажи : rofl:

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

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

Вы автор пакета NuGet и хотите, чтобы они использовали последние версии? Настройте таргетинг на самую последнюю версию netstandard : конечно, изначально только приложения на основе netcoreapp смогут использовать их, но в конечном итоге другие платформы, такие как Xamarin, Mono или .NET Framework, наверстают упущенное и люди смогут использовать ваши пакеты, не требуя от вас ничего менять. Вот как все должно работать.

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

ИМХО, было бы намного лучше сделать так, чтобы ASP.NET Core 3.0 нацелился на новый netstandard TFM, предоставляющий все необходимые API .NET Core. Убедившись, что новые API-интерфейсы достаточно стабильны, перенесите их обратно в .NET Framework, чтобы он был совместим с последним стандартом.

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

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

Мне это не нравится. В начале ядра .net Microsoft не выбирала mono или .net framework в качестве кросс-платформы, и вы сказали, что существует несколько сред выполнения .net, поэтому вы разрабатываете .netstandard , теперь есть еще много пакетов nuget, которые не поддерживают ядро ​​.net (средняя причина). Многие разработчики оставят в стороне старую модель программирования ядра asp.net, если ядро ​​asp.net работает только на ядре .net. тогда .net standard будет существовать только по имени (по крайней мере, для ядра asp.net люди начинают собирать только пакеты netcoreapp ).
Возможно, однажды ядро ​​.net может заменить .net framework в окне, но как насчет моно, а другая платформа полагается на моно (xamarin, unity3d).
и еще одна причина, по которой когда-то я предпочитаю .net framework, заключается в том, что .net core share framework действительно огромен, насколько велика ваша папка C:/program file/dotnet если вы обновляете свое приложение с .net core 2.0 до последней версии .net core 2.1? В моей папке есть файл GB, и он растет, когда я обновляю время выполнения ядра .net. но .net framework просто заменит старую версию.

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

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

Значит, стандарт .net - это шутка? Надеюсь, команда mono будет форкнуть репозитории aspnetcore и переименовать их в aspnetmono, иначе я могу оставить стек .net.😔

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

Конечно, если ваша цель - ничего не менять, вы можете продолжать делать то же самое вечно. Там, где я работаю, мы начали использовать ASP.NET Core пару лет назад, изначально работавшую на .NET Framework. Со временем, когда платформа .NET Core созрела и приобрела новые функции, мы переключили наши проекты на netcoreapp. Один или два старых проекта все еще используют ASP.NET, и мы не планируем их переписывать - это рабочий код. Но из новых вещей мы с нетерпением ждем таких функций, как Span.

Изменения можно отложить, но это не то, чего вы можете или должны избегать навсегда - технологии _is_ изменения, и работа разработчика всегда требует изучения нового. Если вы сегодня используете ASP.NET Core на .NET Framework, вряд ли потребуется три года работы, чтобы переместить его на .NET Core.

Приходите в .NET Core, вода теплая ...

По какой-то причине есть клиенты, которые не могут перейти на .NET Core из-за того, что полагаются только на зависимости .NET Framework ...

Если серьезно, вы можете использовать библиотеки .NET 4.x в .NET Core 2.0, начиная с .NET Standard 2.0 ; хотя есть вероятность, что они могут использовать некоторые функции, которых нет в .NET Core; хотя есть Windows Compatibility Pack для .NET Core, который закрывает множество этих дыр, и многие другие функции поддерживаются в .NET Core 3.0, включая COM-взаимодействие и другие модели приложений, такие как WinForms и WPF и т. д.

Любые блокираторы, препятствующие перемещению приложения ASP.NET Core на .NET Core из .NET Framework, вероятно, должны быть подняты в dotnet / corefx .

Для Xamarin; Я могу ошибаться, но предполагаю, что вы вряд ли будете использовать его для запуска веб-сервера на iOS или Android.

Для клиентских приложений Mono веб-сервер может выйти за пределы процесса и работать в .NET Core, в то время как пользовательский интерфейс работает в Mono. Kestrel никогда не могла работать на платформе Big Endian, которая исключает некоторые другие платформы Mono, хотя разновидности BSD в настоящее время представляют собой пробел в .NET Core.

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

Вне модели приложения ASP.NET Core; например, для библиотек. .NET Standard более важен, поскольку ASP.NET Core имеет всевозможные полезные функции, например Razor.

Не все библиотеки переходят только на .NET Core (например, Microsoft.Extensions.* остаются как .NET Standard), и, вероятно, было бы полезно предоставить конкретные сценарии , которые будут затронуты, как это сделал @daveaglick в https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416, чтобы их можно было принять во внимание; относительно того, какие конкретные библиотеки и / или функции могут быть доступны в .NET Standard, а не просто туманное «все».

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

С другой стороны, было бы хорошо, если бы они были также в версии .NET Standard, чтобы другие среды выполнения могли поддерживать ASP.NET Core 3.0, когда они дойдут до его реализации. На самом деле это произойдет не скоро (поскольку .NET Standard 2.1 еще не доработан, и это должна быть более поздняя версия).

Может быть, модель приложения ASP.NET Core вернется к .NET Standard позже, когда ситуация приблизится? Хотя он всегда может двигаться слишком быстро для процесса .NET Standard, как он сейчас работает?

@gulbanana, что, если ваше ядро ​​asp.net на платформе .net использует com? или есть пакет nuget, который поддерживает только .NET framework?

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

Я думаю, что пакеты 2.1 для .NET Framework обеспечивают хороший путь миграции: переход на 2.1 на netfx, а затем на .NET Core.

Это похоже на AngularJS vs Angular: перенесите существующий код на компоненты (жестко) в последней версии 1. *, затем перейдите к последней версии Angular. Это очень сложно, но выполнимо.

Благодаря новым захватывающим функциям, добавленным как в CoreCLR, так и в моно (например, методы интерфейса по умолчанию или просто быстрый диапазонs), которые никогда не дойдут до .NET Framework, кажется разумным в какой-то момент оставить .NET Framework позади.
Это не обязательно означает «не поддерживать» .NET Framework, а просто оставить все как есть.

Есть еще несколько сайтов, которые используют классический ASP (не ASP.NET, а действительно старые вещи). Он по-прежнему работает и поставляется в Windows, с его помощью вы просто не создадите новые приложения.
Я считаю, что через <10 лет такая же ситуация может возникнуть с .NET Framework.

Я согласен с запрошенной расширенной поддержкой 2.1, но я бы хотел, чтобы команда провела мониторинг загрузок пакетов 2.1, чтобы через 2-3 года принять решение, нужно ли им поддерживать (= исправлять важные проблемы с безопасностью) немного немного длиннее.

@ John0King COM будет поддерживаться в .NET Core 3.0.

Также: у нас есть устаревшие приложения, использующие такие вещи, как .NET Remoting.
Но это уже наследие.

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

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

@gulbanana Это только добавление более высокой планки для переноса приложений из System.Web в ASP.NET Core, поскольку вам нужно изменить веб-фреймворк, базовый фреймворк приложения, а затем обновить или заменить любые несовместимые зависимости (что может потребовать покупки новых лицензии).

Если вы затем проведете анализ затрат и выгод, я не уверен, что это принесет пользу ASP.NET Core.

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

Если вы затем проведете анализ затрат и выгод, я не уверен, что это принесет пользу ASP.NET Core.

Итак .. ну .. оставь это? Если вам не нужно переходить на ASP.NET Core, не делайте этого.
Не пытаюсь показаться саркастичным или что-то в этом роде, но если бизнесу нет необходимости держать приложение на «последних новинках», не переносите его. Преимущество заключается в том, что .NET Framework / ASP.NET classic по-прежнему поддерживается, и ваше приложение будет работать как есть.

Я согласен, что в переносе часто нет необходимости - ASP.NET на ASP.NET Core - это большое изменение, и часть этого изменения заключается в том, что Core перемещается быстрее (в версии 3.0 также будут внесены критические изменения api, как и в версии 2.0). Тем не менее, этот вопрос обсуждения касается изменения netfx на corefx, и для большинства приложений ASP.NET Core это уже не является большим изменением,

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

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

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

• История OData, похоже, все еще витает в воздухе с точки зрения крупномасштабных приложений. Для перехода с OData 3 / System.Data.Services на OData 4 / WebAPI и далее требуется _существенный_ объем (повторной) работы. Это то, что не решается уже несколько лет, и я, честно говоря, не уверен, что это когда-либо будет.

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

Кроме того, теперь нам придется сначала отсечь все другие неподдерживаемые технологии (домены приложений, удаленное взаимодействие и т. Д.), Вместо того, чтобы иметь возможность выполнять эту работу параллельно или на более позднем этапе.

Почему вы не можете сначала перейти на 2.1?

@davidfowl Мы, вероятно, могли бы использовать это в качестве посредника, если только мы не встретим какую-то новую функцию в 3.0 / 3.1 / и т. д. что нам нужно для миграции. Я еще не сделал полного анализа, мы пока в основном заблокированы на EF и OData.

Новая функция в ASP.NET Core 2.1, необходимая для миграции? Я имел в виду ASP.NET Core 2.1 на .NET Framework.

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

представьте себе веб-приложения, которые используют Active Directory или автоматизацию Office COM, или которые делают миниатюры с использованием некоторой библиотеки на основе System.Drawing, или совместно используют код с приложением WPF

Замечательно то, что в .NET Core 3.0 все эти сценарии поддерживаются. Была проделана огромная работа, чтобы это было проще.

@davidfowl я тоже.

Гипотетически может быть какая-то функция, которую мы используем в ASP.NET/MVC/WebAPI, которая не реализована в 2.1, но появилась в более поздней версии. В этом случае 2.1 не будет подходящей ступенькой.

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

@PinpointTownes

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

Вы не ошиблись, но вы в некоторой степени игнорируете цели .NET Standard. Целью стандарта никогда не было стимулирование инноваций, а стимулирование конвергенции. Если вы подойдете к этому с этой точки зрения, то это по дизайну вещь, которая должна отставать, потому что мы должны думать о том, какие концепции могут быть универсальными или даже должны быть универсальными. Если вам интересно, как это выглядит, я приглашаю вас взглянуть на 35+ PR, которые я объединил за последние три недели после проверки всеми владельцами реализации .NET.

Мы рассматриваем .NET Core как передовую платформу, на которой происходят инновации. Мы создали несколько возможностей, которые позволяют нам справляться с оттоком и связанными с этим рисками, намного лучше, чем было у .NET Framework. Однако не все возможности, которые имеют значение для экосистемы .NET, являются частью опыта .NET Core. Например, опережающая компиляция гораздо более заметна в Xamarin и Unity. И когда мы берем функции .NET Core и добавляем их к стандарту, нам необходимо учитывать их среды выполнения, операционные системы и аппаратные ограничения.

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

Реальность такова, что «быстро двигаться и ломать голову» - это не то, что ценится всей нашей аудиторией. Достаточно плохо, если нам придется удалить API из основных версий .NET Core, но это практически невозможно сделать с .NET Standard. Таким образом, мы должны действовать несколько медленнее и включать только те концепции, которые, по нашему мнению, достаточно зрелы для добавления.

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

Это все еще предполагает, что .NET Framework в конечном итоге получит все возможности .NET Core, но с задержкой по времени. Мы узнали, что это просто нереально. Мы можем либо отказаться от радикальных инноваций в .NET Core, либо согласиться с технической реальностью, согласно которой значительная часть новых функций никогда не вернется в .NET Framework. Мы считаем, что обслуживаем наших клиентов наилучшим образом, чтобы сохранить основную ценность .NET Framework (зрелую и богатую платформу разработки), а также позволяя клиентам использовать новые возможности .NET Core. Двигаясь вперед, я ожидаю, что мы с большей охотой будем вводить новшества в областях, требующих изменений среды выполнения, библиотеки и языка, как мы это сделали для Span<T> . Хотя эти вещи дороги, они также позволяют нам изменить способ написания кода людьми. Хорошим примером этого являются реализации интерфейсов по умолчанию, возможность создавать общий код, включающий арифметику, возможность использовать встроенные аппаратные средства и т. Д. И эти функции, скорее всего, являются именно такими, которые мы не собираемся переносить на .NET Framework из-за риска .

Я думаю, что для нашего веб-стека имеет смысл использовать эти возможности; и единственный способ сделать это - снять ограничение на запуск ASP.NET Core и на .NET Framework. Имейте в виду, что первоначальная причина, по которой мы сделали ASP.NET Core работающим на .NET Framework, заключалась в том, что в .NET Core просто не хватало API. В .NET Core 3.0 у нас будет более 120 тысяч существующих API . Это больше половины всей .NET Framework и даже включает WinForms и WPF. Да, по-прежнему отсутствует большое количество API, но мы сделали огромные шаги в сторону «длинного хвоста». Несмотря на то, что у нас никогда не будет 100% паритета, я ожидаю, что мы восполним этот пробел в дальнейшем, основываясь на данных о клиентах.

@ yaakov-h Я был бы удивлен, если бы это было так. Когда сделаете анализ, дайте мне знать.

Вы не ошиблись, но вы в некоторой степени игнорируете цели .NET Standard. Целью стандарта никогда не было стимулирование инноваций, а стимулирование конвергенции.

И вы идете прямо в противоположном направлении: отказ от .NET Standard для ASP.NET Core, поскольку он движется недостаточно быстро, вынуждая пакеты NuGet, ориентированные на ASP.NET Core, также отказаться от него. Не заставляйте меня думать, что это конвергенция, я не такой уж невежественный : rofl:

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

Это выбор, а не техническая проблема: ничто не мешает вам определить, следует ли включать данный API в новую версию .NET Standard при его проверке на предмет включения в corefx / coreclr.

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

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

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

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

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

Что мешает вам представить новую параллельную версию .NET Framework (скажем, .NET Framework 5), которая включает эти «рискованные» изменения? Опять же, это не техническая проблема.

Есть ли шанс продвинуть Microsoft.AspNetCore.Razor.Language и Microsoft.AspNetCore.Razor за пределами aspnet или оставить их на волне netstandard ? Несмотря на то, что razor предназначен только для html, существует несколько библиотек, которые используют его для почтовых шаблонов, и было бы здорово, если бы мы могли продолжать использовать его как есть.

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

Следует ли разработчикам .NET ожидать этого шага в отношении всех других новых библиотек, разрабатываемых Microsoft в открытом доступе? Может ли сообщество получить более официальное заявление о будущем netstandard и его принятии?

@terrajobst Я полностью понимаю, что вы указываете на то, что не добавляете в .netstandard те API, которые, похоже, не готовы для охвата всех платформ (и, вероятно, никогда не будут). Однако это не помешало вам (MS) ввести netstandard2.0, когда, например, UWP не был готов его поддерживать. Как я понимаю, через некоторое время потребовались заметные усилия, чтобы добавить эту поддержку, но вы это сделали. Это была какая-то другая история?

И вы идете прямо в противоположном направлении: отказываетесь от .NET Standard в пользу ASP.NET Core, потому что он движется недостаточно быстро.

ASP.NET Core имеет смысл только в .NET Framework и .NET Core, но .NET Standard должен быть реализован всеми. Например, просто не имеет смысла заставлять Xamarin / Unity предоставлять API-интерфейсы, которые преимущественно используются серверным веб-стеком.

Это выбор, а не техническая проблема: ничто не мешает вам определить, следует ли включать данный API в новую версию .NET Standard при его проверке на предмет включения в corefx / coreclr.

Это то, что мы делали в .NET Core v1 days. Мы отделили стандарт от .NET Core с помощью v2. Так что да, это выбор, но не произвольный. Целью было ускорить работу с .NET Core. Просто требуется больше времени, чтобы рассмотреть, как функции работают в контексте N других сред выполнения, чем в одной.

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

Нет, это болезненный процесс, потому что вам нужно пересмотреть проект с несколькими разработчиками и несколькими разными средами выполнения. Однако делать это постфактум, объединять и объединять гораздо дешевле, чем координировать это по ходу дела. Репо CoreFx - это репо с большим объемом. Для Xamarin и Unity гораздо проще просматривать объединенные функции, чем пить из пожарного шланга и подписываться на все обсуждения API на CoreFx.

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

И поскольку вам это не нравится, вы хотите навязать это всем, сделав .NET Standard похожим на .NET Core? Извините, но этот аргумент для меня не имеет смысла.

Что мешает вам представить новую параллельную версию .NET Framework (скажем, .NET Framework 5), которая включает эти «рискованные» изменения? Опять же, это не техническая проблема.

Почему вы думаете, что это не техническая проблема? Доставка параллельных версий .NET Framework не является приемлемым решением. Во-первых, это довольно дорого из-за того, что это компонент ОС и, следовательно, требует обслуживания. Вы не представляете, насколько сложна наша стратегия ветвления / обслуживания / исправления для .NET Framework 3.5 и 4.x. Добавление третьего почти нецелесообразно. Во-вторых, это тоже сопряжено с риском, поскольку нам нужно внести изменения в активацию, чтобы выбрать правильную среду выполнения для таких вещей, как управляемые компоненты, активируемые COM. И это вызывает вопрос о том, поддерживаем ли мы также параллельную работу внутри процесса и с каким количеством комбинаций. Это непростая задача и тоже небезопасная.

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

@PinpointTownes Это конвергенция ... на .NET Core 😉

Например, просто не имеет смысла заставлять Xamarin / Unity предоставлять API-интерфейсы, которые преимущественно используются серверным веб-стеком.

Есть люди, которые хотели бы использовать ASP.NET Core не только в .NET Core, но и в UWP, так почему бы не использовать еще и Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

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

Репо CoreFx - это репо с большим объемом. Для Xamarin и Unity гораздо проще просматривать объединенные функции, чем пить из пожарного шланга и подписываться на все обсуждения API на CoreFx.

Я предлагал такой крайний подход? Я уверен, что вы можете найти компромисс, например, обсудить новые стандартные API-интерфейсы вскоре (то есть через несколько недель) после их введения в .NET Core, когда пыль немного уляжется.

И поскольку вам это не нравится, вы хотите навязать это всем, сделав .NET Standard похожим на .NET Core? Извините, но этот аргумент для меня не имеет смысла.

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

Я не уверен, что заставить .NET Standard двигаться так же быстро, как .NET Core, можно рассматривать как наказание: ничто не заставляет вас нацеливаться на последний netstandard TFM. Вы сделаете это только в том случае, если вам понадобится последний набор API. Если вам это не нужно, выберите более старую версию, чтобы ваши пакеты могли использоваться на более широком наборе платформ.

С точки зрения среднего разработчика, это полная победа: вы можете писать пакеты, используя новейшие блестящие API-интерфейсы, которые могут использоваться новейшей средой выполнения .NET Core. Когда другие платформы догонят, ваши пакеты можно будет использовать и там: вам не нужно использовать мульти-таргетинг или повторно публиковать пакеты.

Во-первых, это довольно дорого из-за того, что это компонент ОС и, следовательно, требует обслуживания. Вы не представляете, насколько сложна наша стратегия ветвления / обслуживания / исправления для .NET Framework 3.5 и 4.x. Добавление третьего почти нецелесообразно.

Я могу себе представить, что это не идеально для вас, так же как удаление поддержки .NET Framework для ASP.NET Core 3.0 не будет идеальным для людей, которые не могут перейти на .NET Core. Но я совершенно ошибаюсь, полагая, что у вас - Microsoft - гораздо больше ресурсов, чтобы справиться с этим, чем у средней компании для перехода на .NET Core? (Я даже не говорю о внешних зависимостях, которыми вы не владеете и не контролируете).

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

Конечно, это непросто. И это рискованно. Но это то, что указывают основные версии: есть риск поломки. Теперь, когда вы вынуждены навсегда остаться на ASP.NET Core 2.2 и рискнуть перейти на .NET Framework 5 для использования ASP.NET Core 3.0, что, по вашему мнению, люди выберут?

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

По моему опыту, люди постоянно переоценивают количество имеющихся у нас ресурсов и объем работы, которую нам приходится выполнять, чтобы поддерживать статус-кво.

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

Теперь, когда вы вынуждены навсегда остаться на ASP.NET Core 2.2 и рискнуть перейти на .NET Framework 5 для использования ASP.NET Core 3.0, что, по вашему мнению, люди выберут?

На мой взгляд, гораздо практичнее расширять спектр поддерживаемых API-интерфейсов в .NET Core, чтобы дать возможность большему количеству людей беспрепятственно перейти на .NET Core, чем пытаться переносить функции .NET Core обратно в .NET Framework. Все, что мы можем сделать - это причинить горе. Имейте в виду, что параллельные выпуски сопряжены с другими проблемами, такими как получение ИТ-специалистами возможности установить его, привязка его к установщикам или ожидание, пока ваш хостер предоставит вам машины и т. Д.

Применимо ли это ко всем частям ASP.NET Core, или некоторые полезные, обычно повторно используемые части (например, Microsoft.AspNetCore.Http.Extensions ) останутся в .NET Standard?

@andriysavin

@terrajobst Я полностью понимаю, что вы указываете на то, что не добавляете в .netstandard те API, которые, похоже, не готовы для охвата всех платформ (и, вероятно, никогда не будут). Однако это не помешало вам (MS) ввести netstandard2.0, когда, например, UWP не был готов его поддерживать. Как я понимаю, через некоторое время потребовались заметные усилия, чтобы добавить эту поддержку, но вы это сделали. Это была какая-то другая история?

Да. В .NET Standard 2.0 не было никаких новых API. Он был определен как пересечение .NET Framework и Xamarin. Какой бы ни была дельта, она нам просто нужна, чтобы достичь разумной панели совместимости с существующим кодом. Единственная работа была в UWP и .NET Core. И эти кодовые базы изначально были разработаны как современная перезагрузка .NET, которая, как мы выяснили, нежизнеспособна. Поскольку API / технологии, которые должны были быть добавлены, были в значительной степени зрелыми и поддерживались в ограниченных средах (Xamarin iOS), сложность была низкой - всего тонна работы по переносу.

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

По моему опыту, люди постоянно переоценивают количество имеющихся у нас ресурсов и объем работы, которую нам приходится выполнять, чтобы поддерживать статус-кво.

По моему опыту, Microsofties постоянно переоценивают количество имеющихся у нас ресурсов и объем работы, который нам нужно сделать, чтобы поддерживать статус-кво в одиночку. Ваш аргумент действительно работает в обоих направлениях: sweat_smile:

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

Давайте проясним: я полностью за это , но это не сработает, пока .NET Core не догонит и не реализует большинство / все функции .NET Framework. Пока этого не произойдет, вы по-прежнему будете видеть, что людей блокируют из-за отсутствующей функции или API. Так много чего не хватает, поэтому неразумно думать, что большие устаревшие монолитные приложения смогут перейти на .NET Core без проблем.

Я определенно понимаю ваши опасения. Но в конечном итоге то, что делает вашу жизнь проще, может сделать нашу жизнь еще более болезненной: отказ от поддержки .NET Framework станет для нас PITA.

Я определенно понимаю ваши опасения. Но в конечном итоге то, что делает вашу жизнь проще, может сделать нашу жизнь еще более болезненной: отказ от поддержки .NET Framework станет для нас PITA.

Я понимаю эту часть. Но альтернативой было бы не больше возможностей .NET Framework, а просто менее мощное ядро ​​ASP.NET.

В последние годы мы пытались совместно развивать .NET Framework и .NET Core. Не то чтобы мы избегали работы. Я лично потратил миллионы часов на разговоры с нашими инженерами среды выполнения, пытаясь исправить, например, кошмар перенаправления привязки. Или сломанная поддержка .NET Standard 2.0 в 4.6.1. Мы старались. Дело не в силе воли, а в практичности.

он не будет работать, пока .NET Core не догонит и не реализует большинство / все функции, которые были в .NET Framework

В моем опыте, наличие некоторых API , даже не это актуально. Что очень важно в корпоративной среде, так это сложность поддержки и развертывания. И «поддерживается, поставляется и автоматически обновляется вместе с операционной системой» намного привлекательнее, чем трехлетняя поддержка, которую мы получаем от выпусков .NET Core LTS, и сложное развертывание, которое она до сих пор требует. И давайте будем честными: до сих пор нет стабильного инструментария для .NET Core и ASP.NET Core, я могу с уверенностью сказать, что через год он все равно будет существовать. У нас были изменения с каждым выпуском, и кто знает, будет ли новая ссылка на фреймворк с 3.0 правильным решением. Так что это определенно большая проблема при работе с корпорациями, где вы не можете просто обновить что-то или сделать это так, как нужно; обычно они хотят, чтобы это было сделано так, как они делали это последние 5+ лет. Они испорчены фреймворком, и все, что для них не так удобно, почти беспокоит.

Но альтернативой было бы не больше возможностей .NET Framework, а просто менее мощное ядро ​​ASP.NET.

Это в значительной степени то, что я предлагал в прошлом году: пакеты ASP.NET Core, которые все еще работают на .NET Framework (например, с помощью таргетинга netstandard20 и netcoreapp30 ), но предлагают более ограниченный набор функций с гораздо меньшими интересный спектакль. Иногда люди хотят того, что работает. Не новые блестящие вещи. Не супербыстрый.

В последние годы мы пытались совместно развивать .NET Framework и .NET Core. Не то чтобы мы избегали работы. Я лично потратил миллионы часов на разговоры с нашими инженерами среды выполнения, пытаясь исправить, например, кошмар перенаправления привязки. Или сломанная поддержка .NET Standard 2.0 в 4.6.1. Мы старались. Дело не в силе воли, а в практичности.

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

Мне очень жаль быть таким парнем: sweat_smile:

До сих пор на фронте ASP.NET Core я видел, как Razor представлял собой нечто конкретное, что люди хотели бы сделать доступными вне ASP.NET Core в целом. Я думаю, что это разумно, и нам следует выделить больше таких областей (это будет более полезное обсуждение). ASP.NET Core 2.1 и 2.2 по-прежнему будут поддерживать .NET framework, но я не считаю разумным поддерживать .NET Framework навсегда.

@terrajobst

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

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

До сих пор на фронте ASP.NET Core я видел, как Razor представлял собой нечто конкретное, что люди хотели бы сделать доступными вне ASP.NET Core в целом.

Вы можете добавить в список пакет Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection и соответствующие зависимости .

Это в значительной степени то, что я предлагал в прошлом году: пакеты ASP.NET Core, которые все еще работают на .NET Framework (например, с помощью таргетинга netstandard20 и netcoreapp30 ), но предлагают более ограниченный набор функций с гораздо меньшими интересный спектакль. Иногда люди хотят того, что работает. Не новые блестящие вещи. Не супербыстрый.

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

@HaloFour

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

Я думаю, вы объединяете устаревший код с существующими установками . Даже если бы мы перенесли DIM на .NET Framework, вам все равно пришлось бы перейти на более новую версию, чтобы использовать эту функцию. Хотя это, вероятно, функция, предназначенная только для .NET Core, она все же позволяет нам развивать .NET Core, сохраняя при этом возможность использовать код, скомпилированный для .NET Framework.

@terrajobst Вы все время упоминаете о Unity. Есть ли у них собственная реализация CLR? У меня создалось впечатление, что они используют Mono.

Unity имеет несколько реализаций .NET, включая их собственную немоно-версию AOT, IL2CPP. Их библиотека классов и поддерживаемые API также отличаются от стандартного Mono.

@terrajobst

Я думаю, вы объединяете устаревший код с существующими установками.

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

Хотя это, вероятно, функция, предназначенная только для .NET Core, она все же позволяет нам развивать .NET Core, сохраняя при этом возможность использовать код, скомпилированный для .NET Framework.

С какой целью? Ни один из этих «усовершенствованных» API в .NET Core никогда не будет применим к .NET Standard. И ни один писатель библиотеки не коснется этого, учитывая, как это создаст несовместимое расхождение в их собственных API.

Я согласен с @HaloFour. Единственные люди, которые смогут использовать DIM, - это те авторы библиотек, которые нацелены только на .NET Core ... так что в основном только corefx и aspnetcore. Я не могу представить, чтобы кто-то другой подошел к этому.

Единственные люди, которые смогут использовать DIM, - это те авторы библиотек, которые нацелены только на .NET Core ... так что в основном только corefx и aspnetcore.

Другими словами, единственной платформой, на которой вы не можете ее использовать, будет .NET Framework, тогда как вы можете использовать .NET Core, Xamarin, Mono и Unity.

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

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

@ yaakov-h

Применимо ли это ко всем частям ASP.NET Core ...

Предварительный список того, что происходит с каким пакетом, находится здесь: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Я думал, что реализации интерфейса по умолчанию будут частью языка C #. Говоря, что .NET Framework не поддерживает его, вы фактически говорите, что .Net Framework навсегда застрянет с C # версии 7.3 или, самое большее, следующей. Такое расхождение - это не то, чего никто не хотел бы иметь в экосистеме.

Мы выполняем несколько рабочих нагрузок .NET Core, но также выполняем многолетние проекты .NET FX.

Безопасное обновление до .NET Core (даже на .NET Framework для начала) - очень большая задача.

Есть ли у Microsoft какие-либо планы по выпуску инструментов, которые помогут «обновить» проекты как минимум с ASP.NET на .NET FX до ASP.NET Core и .NET FX?

Есть статьи MSDN о создании новых проектов VS, импорте представлений и перенастройке проектов, но существует так много устаревшего материала (глобальный асакс, маршрутизация и т. Д.), Что мне хотелось бы, чтобы было центральное место, в котором документировались старые и новые способы помощи все портирую.

Что мешает вам представить новую параллельную версию .NET Framework (скажем, .NET Framework 5), которая включает эти «рискованные» изменения?

В этом случае есть ли преимущества в том, что это не .NET Core 3.0? Он уже идет бок о бок и имеет «рискованные» изменения. Потребуется ли для следующего набора функций .NET Core .NET Framework 6 и т. Д.?

С apis уже в .NET Core 2.0 и с новым набором функций, который появится в .NET Core 3.0, разве .NET Core не выполняет «.NET Framework 5», а Framework 4.x является чрезвычайно длинной LTS-версией?

Предположительно; на этом этапе было бы менее сложной инженерной задачей покрыть любые конкретные выявленные пробелы, которые .NET Core 3.0 имеет от .NET Framework 4.x, вместо того, чтобы изменять .NET Framework так, чтобы он работал как .NET Core.

Практическое предложение: есть ли шанс, что ASP.NET Core 2.2 станет LTS с расширенным сроком поддержки, превышающим обычные 3 года?

Я уверен, что это удовлетворит тех, кому нужно придерживаться полной структуры на данный момент, а также даст им (1) достаточно времени для фактического перехода на .NET Core и (2) достаточную мотивацию для перехода с ASP.NET MVC на ASP. .NET Core (когда они не могут перейти на .NET Core _yet_).

Я до сих пор не думаю, что это ясно, следует ли ASP.NET Core на .NET Framework .NET Core 2.1 LTS или он следует циклу поддержки .NET Framework v4.6.1 + (т.е. поскольку он работает на .NET FX), где это поддерживается в обозримом будущем?

@mythz ASP.NET Core входит в жизненный цикл поддержки .NET Core , независимо от того, на какой платформе вы его запускаете.

Я думаю, что лучшим шагом здесь было бы действительно обновить стандарт .net как минимум до 3.0, 4.0 и 5.0 и фактически сообщить, что в какой-то момент инфраструктура .net будет полностью перенесена на ядро ​​.net.
все остальное просто наполовину испечено.

Ребята, у вас есть клиенты, которые уже сегодня платят за поддержку LTS? (Просто вопросительный вопрос). Сколько времени достаточно времени?

@terrajobst Похоже, настоящая проблема в том, что netstandard является монолитным. Похоже, нам не нужен netstandard, а вместо этого нужны версионные наборы API. Это также будет TFM, например, base2.0 + span будет двумя наборами API.

Затем вы можете развить стандарт на основе наборов API и, возможно, реализовать только некоторые наборы API в полной структуре. (Это также упростило бы реализацию netstandard на других платформах, поскольку некоторые наборы API можно не учитывать).

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

@Sebazzz , это очень странная тема. Не можем ли мы сорвать эту ветку попытками изменить дизайн netstandard? Для этого вы можете подать вопрос в dotnet / standard, но я скажу вам, что эта идея уже была предложена и опровергнута.

@davidfowl Я не думаю, что это вообще "странно" или "

@Sebazzz @masonwheeler

@terrajobst Похоже, настоящая проблема в том, что netstandard является монолитным. Похоже, нам не нужен netstandard, а вместо этого нужны версионные наборы API. Это также будет TFM, например, base2.0 + span будет двумя наборами API.

Мы пробовали это в различных вариантах (профили, PCL, свободные контракты, а затем наборы контрактов с управлением версиями, которые стали .NET Standard 1.x). Слишком сложно использовать и понять правила совместимости с течением времени (когда версии платформ и наборы API развиваются). .NET Standard в его нынешнем виде - это наиболее близкая к работоспособной модели из когда-либо существовавших. Хотя это и не идеально, по крайней мере я могу объяснить это за несколько минут и не дать людям взорваться.

Я счастлив обсудить .NET Standard более подробно, но я согласен с @davidfowl, что это здесь не место. Если хотите, сообщите о проблеме на странице https://github.com/dotnet/standard.

Изменить Я пометил наши комментарии .NET Standard как не по теме.

@ Шаян-То

@terrajobst Я думал, что реализации интерфейса по умолчанию будут частью языка C #. Говоря, что .NET Framework не поддерживает его, вы фактически говорите, что .Net Framework навсегда застрянет с C # версии 7.3 или, самое большее, следующей. Такое расхождение - это не то, чего никто не хотел бы иметь в экосистеме.

Это функция, которая требует изменения языка, а также изменения среды выполнения. Он похож на дженерики, поскольку меняет правила системы типов. Вообще говоря, C # не знает, для какой платформы вы компилируете (ему просто передается набор ссылочных сборок, описывающих API, предлагаемые платформой). Будет поддерживаться любая функция C #, которая не требует изменений API (например, оператор объединения с нулевым значением ?. или _ для отбрасывания выражений). В этом он идентичен тому, как всегда работал компилятор, когда вы использовали последнюю версию компилятора и языка и ориентировались на старую версию .NET Framework, в которой отсутствуют соответствующие API. Например, async / await не будет работать, если вы нацеливаетесь на .NET Framework 3.5 или 4.0 - вам нужно быть на 4.5 или выше, чтобы использовать Task .

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

Однако люди будут расстроены из-за этого ... Значительная часть этого - общение. Когда было объявлено о 3-летнем LTS 2.1, люди, использующие fullfx, должны были иметь возможность перейти на 3.0 и по-прежнему использовать fullfx, они продали ядро ​​asp.net своим работодателям и клиентам, поставив на кон свою репутацию теперь они будут чувствовать, что под ними выдернули коврик. То, что они продали как долгосрочное решение, будущее asp.net, теперь (с точки зрения восприятия) ограничено 3 годами поддержки.

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

Большинство разработчиков _ захотят_ перейти на .net core 3, но, помимо потенциально возможных зависимостей, которые они не могут изменить (или связаны с изменением риска), они теперь должны снова начать миграцию и пообещать, что на этот раз это будет долгосрочное вложение. ... это может быть трудная продажа, но они будут чувствовать себя вынужденными сделать это из-за трехлетнего цикла поддержки.

Опять же, я за отказ от fullfx, но я действительно думаю, что вам следует рассмотреть возможность расширения LTS для последней версии, которая поддерживает его в значительной степени. Также очень четкое общение, например, в блогах, на конференциях / сессиях и т. Д., Какие части будут по-прежнему оставаться стандартными и как люди, все еще использующие 2.1 / полную структуру, могут по-прежнему использовать их.

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

Какое разумное время для LTS?

Может, лет 6? Я думаю, что обмен сообщениями будет играть огромную роль в приеме ... В конце концов, некоторые люди будут расстроены, несмотря ни на что: /

@davidfowl @ aL3891

Для справки: «Премьер-поддержка» Java LTS составляет 5 лет, а «Расширенная поддержка» (платная) - еще три года. Java 11, выпуск LTS, выпущенный в прошлом месяце, будет поддерживаться до сентября 2023 г. и сентября 2026 г. соответственно.

Мы изучаем предложение LTS «расширенной поддержки» и предоставим более подробную информацию, когда они у нас появятся. Это потенциально может предложить клиентам, которым требуется поддерживаемое ядро ​​ASP.NET в версии .NET Framework (2.1.x), вариант, более длительный, чем текущий период поддержки LTS.

Кроме того, к вашему сведению, я немного поговорил об объявлениях сегодня на форуме сообщества ASP.NET: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Таргетинг на стандарт .net, пожалуйста. Ядро asp.net может нацеливаться на .netstandard2.1 или 3.0 и позволить mono и .netframework догнать позже, но если ядро ​​asp.net нацелено на netcoreapp , то любая библиотека попытается получить доступ к типу из этой библиотеки aspnetcore должна быть библиотека .netcoreapp .

и ядро ​​.net всегда будет выпускаться быстрее, чем .net framework и mono ,
mono и .netframework в конечном итоге будут потреблять сборки .netcoreapp если Microsoft начнет нацеливать больше фреймворков / библиотек на netcoreapp (это также приведет к увеличению библиотеки на целевом объекте nuget .netcoreapp ).

если это так, .netstandard превратится в .netcoreapp 😂

@ John0King, пожалуйста, приведите примеры типов, которые вам нужны вне ASP.NET Core.

1. Бритва, как упомянул @poke
2. Интерфейсы / атрибуты фильтров MVC (у меня есть библиотека вспомогательных классов, которая содержит некоторые ActionFilters и TagHelpers, а также общий статический метод / метод расширения для строк, int, long и т. Д. Я использую PrivateAssert="All" для ссылки на пакеты MVC, поэтому, когда я использую это библиотека где-то еще, этот проект не должен ссылаться на сборки MVC, я думаю, мне нужно разделить библиотеку на два, один - .netstandard а другой .netcoreapp )

Другой вопрос: возникнет ли проблема, для какого типа библиотеки классов мне следует создать? ( .netstandard против .netcoreapp ). В asp.net core 2.1 сегодня все довольно просто. выберите .netstandard для библиотеки классов, выберите .netcoreapp или net461 для веб-проекта.

mono и .netframework в конечном итоге будут потреблять сборки .netcoreapp, если Microsoft начнет нацеливать больше фреймворков / библиотек на netcoreapp (это приведет к увеличению библиотеки на целевом элементе nuget.

Это произойдет, если люди не будут стараться изо всех сил разделять то, что должно поступать в библиотеку .netstandard а что - в библиотеку .netcoreapp

Интерфейсы / атрибуты фильтров MVC (у меня есть библиотека вспомогательных классов, которая содержит некоторые ActionFilters и TagHelpers, а также общий статический метод / метод расширения для строк, int, long и т. Д. Я использую PrivateAssert = "All" для ссылки на пакеты MVC, поэтому, когда я использую эту библиотеку где-то еще, этот проект не должен ссылаться на сборки MVC, я думаю, мне нужно разделить библиотеку на два, один - .netstandard, а другой .netcoreapp)

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

@davidfowl эта библиотека является вспомогательной библиотекой классов, я могу использовать эти фильтры, когда работаю в основном проекте MVC asp.net, и использую его методы расширения только в консольном приложении.

@davidfowl эта библиотека является вспомогательной библиотекой классов, я могу использовать эти фильтры, когда работаю в основном проекте MVC asp.net, и использую его методы расширения только в консольном приложении.

Я все еще не понимаю. Вы говорите о библиотеке, в которой есть вещи MVC и другие случайные вещи?

К сожалению, такого рода вещи распространены в корпоративном программном обеспечении - «вспомогательные библиотеки», в которых есть, например, служебные программы компании для MVC + служебные программы компании для WPF + служебные программы компании для Telerik ...
Это имело больше смысла, когда .NET была единой унифицированной платформой.

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

Да ладно, это просто заставляет ваши библиотеки быть лучше наслоены 😉

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

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

Очень хотелось бы получить ответ от команды .net по этому поводу.

Дело в том, что ASP.NET Core - это веб-фреймворк. В какой отрасли безопасно запускать веб-сайт без изменений > трех лет? Если это не уязвимости безопасности, это будут браузеры, не поддерживающие то, на что вы полагались, или TLS 1.4, или пользователи, требующие, чтобы сайт работал на их новом наблюдателе.

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

Я думаю, что это было бы более приемлемо для сообщества, если бы вы просто увеличили период LTS для ASP.NET Core 2.1 до 5-7 лет.

По нашему опыту, корпоративная корпоративная разработка движется медленными темпами по сравнению с «современной» веб-разработкой, и тем не менее они все же хотят быть уверенными, что не делают новых инвестиций на значительно более старые платформы. Для запуска этих приложений часто требуется больше года, не говоря уже о том, чтобы сделать серьезное обновление за 3 года. Эти корпоративные (обычно только внутренние) веб-приложения часто поддерживаются в течение 7-10 лет, хотя я считаю неразумным, чтобы срок действия LTS для ASP.NET Core 2.1 составлял 10 лет. 5 лет кажется лучшим решением, чем 3, при этом 7 лет - это цифра, которая наверняка устроит почти всех.

И это необходимо только потому, что ASP.NET Core 3.0 требует серьезного критического изменения, удаляющего поддержку .NET Framework. Будущие выпуски LTS не должны соответствовать этому стандарту, если критические изменения не такие уж и большие.

Я не уверен, что заставить .NET Standard двигаться так же быстро, как .NET Core, можно рассматривать как наказание: ничто не заставляет вас нацеливаться на последний netstandard TFM. Вы сделаете это только в том случае, если вам понадобится последний набор API. Если вам это не нужно, выберите более старую версию, чтобы ваши пакеты могли использоваться на более широком наборе платформ.

Что, если платформа никогда не догонит? Тогда у вас будет библиотека, нацеленная на netstandard2.3 которой нужна функция A, которая доступна только в .NET Core и Xamarin, но невозможна для .NET Framework.

Затем выходит netstandard2.4 с несколькими новыми API-интерфейсами, и некоторые из этих API-интерфейсов можно переносить на .NET Framework. Что теперь?

Как настроить таргетинг на библиотеку, которой нужна функция netstandad2.4, которая работает на .NET Framework, но netstandard2.4 не может нацеливаться на .NET Framework, потому что не может реализовать netstandard2.2 .

Тогда вам придется выполнить кросс-компиляцию для трех платформ:
netstandard2.2 для старых платформ и net4x для сетевого стандарта только для поддержки функции, которая была добавлена ​​в netstandad2.4 и которая net4x can also implement but not support because of APIs that went into netstandard2.3`.

Как это упростило бы авторам пакетов написание и отправку своих пакетов-слепков?

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

Я могу себе представить, что это не идеально для вас, так же как удаление поддержки .NET Framework для ASP.NET Core 3.0 не будет идеальным для людей, которые не могут перейти на .NET Core. Но я совершенно ошибаюсь, полагая, что у вас - Microsoft - гораздо больше ресурсов, чтобы справиться с этим, чем у средней компании для перехода на .NET Core? (Я даже не говорю о внешних зависимостях, которыми вы не владеете и не контролируете).

В чем здесь актуальная проблема? Люди, которые не могут перейти с ASP.NET Legacy на ASP.NET Core, не смогут перейти, независимо от того, нацелен ли ASP.NET Core на .NET Framework или нет. Наиболее вероятная причина, по которой они не могут или не будут, будут связаны с библиотеками System.Web , которые не будут работать ни на ASP.NET Core на .NET Framework. У людей, у которых сейчас есть свои приложения, очевидно, уже есть рабочий набор.

А люди, которые уже используют ASP.NET Core 2.1 на .NET Framework, если он работает, почему они хотят переехать? Очевидно, что все необходимое уже есть, а все остальное, что появляется недавно в ASP.NET Core 3.0, приятно иметь.

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

Что, если платформа никогда не догонит? Тогда у вас будет библиотека, нацеленная на netstandard2.3, которой нужна функция A, которая доступна только в .NET Core и Xamarin, но невозможна для .NET Framework.

Если API не может быть реализован на большинстве платформ, поддерживающих .NET Standard, то велики шансы, что он не должен быть частью стандарта, не так ли? (на практике, скорее всего, наоборот, поскольку платформы, на которых работает Xamarin, как правило, гораздо более ограничены). Я ожидал, что такая проблема будет обнаружена при просмотре API для включения в .NET Standard, но могу ошибаться.

А люди, которые уже используют ASP.NET Core 2.1 на .NET Framework, если он работает, почему они хотят переехать?

• Служба поддержки? (3 года поддержки - это безумно мало)
• Исправление ошибки присутствует только в версии 3.0? (В LTS-версиях исправлены только критические ошибки и уязвимости)
• Вам нужно сослаться на библиотеку, совместимую только с последней версией ASP.NET Core?

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

Да, конечно, теоретически это идеальный способ справиться с этим. Но:

• Некоторые приложения зависят от внешних библиотек, которые вы не контролируете. Если библиотека не работает на .NET Core, а поставщик не хочет (или не может) переносить ее, вам не повезло.
• Переход на .NET Core может быть дорогостоящим и трудоемким. Если даже лучшие команды Microsoft борются с этим, неужели вы думаете, что это будет так просто для любой средней команды? Нам придется подождать версии 3.0, чтобы увидеть, что Entity Framework 6 наконец-то станет совместимым с .NET Standard.

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

Microsoft, было бы слишком много просить о расширении поддержки 2.1? 2021 год для нас недостаточен, и у нас нет достаточно ресурсов / времени, чтобы осуществить это преобразование. Может, хотя бы до 2022 года? Дополнительный год действительно дал бы нам шанс внести изменения, хотя и болезненные.

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

К вашему сведению https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

Хотя я рассматриваю возможность расширения LTS по мере необходимости, ИМО следует также рассмотреть вопрос о переходе ASP.NET Core на .NET FX в цикл поддержки .NET FX. Для начала сбивает с толку наличие разных частей .NET Framework на разных циклах поддержки, когда объединение их вместе имело бы больше смысла. Во-вторых, код для 2.1 уже написан, выпущен и зависит от него, поэтому для его поддержки потребуется гораздо меньше ресурсов, чем для его активной разработки в связке с .NET Core 3.0. Если одна и та же команда поддерживает и то, и другое, я бы также предположил, что недавнюю и более знакомую модульную активную базу кода ASP.NET Core будет легче поддерживать, чем полностью другую классическую базу кода ASP.NET.

Когда MS анонсировала EOL Silverlight 5 в 2012 году, они все еще поддерживали его до октября 2021 года (несмотря на то, что он был отключен в Chrome в 2015 году и Firefox в 2017 году). Это для технологии, которая полностью заброшена, что здесь не так, в основном та же кодовая база, модель программирования, активная команда разработчиков все еще работает над этим, это только запускает существующее программное обеспечение на .NET Framework, которое заброшено.

До этого объявления был сильный обмен сообщениями, MS никогда не отказывался от .NET Framework, что он отлично подходит для рабочих нагрузок только для Windows (в отличие от .NET Core для кроссплатформенных / высокопроизводительных рабочих нагрузок) и что будущее за ASP.NET Core. модель программирования, которая в будущем будет поддерживать как .NET Framework, так и .NET Core с .NET Standard в качестве решения для разработки библиотек, ориентированных на несколько платформ.

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

Если бы мне пришлось поддерживать системы на .NET Framework, я бы предпочел разрабатывать их на новой модели программирования ASP.NET с доступом к активной базе знаний / экосистеме, а затем был бы вынужден вернуться к использованию старого ASP.NET. на неопределенный срок, но это будет невозможно, если ASP.NET Core на FX не будет иметь такой же уровень поддержки, что и WebForms.

MS также имеет возможность позиционировать ASP.NET Core на FX как «стабильную» среду разработки (т.е. фиксированную на ASP.NET Core 2.1). В последние несколько лет с момента появления .NET Core было нелегко быть .NET-разработчиком. Нам фактически пришлось отказаться от всех наших усилий по переносу на .NET Core <1.x, так как было трудно угнаться за постоянным потоком критических изменений, и только до .NET Core 2.x мы смогли для его поддержки и переноса существующих приложений. С другой стороны, существующие разработчики ASP.NET Framework видели, как выбранная ими платформа стагнирует, а затем заменяется новой моделью программирования ASP.NET Core и расширением, разрушающим их существующие навыки / знания. Прекращение поддержки ASP.NET Core на FX убивает популярную стратегию поэтапной миграции на .NET Core, где они рискуют (без резервного отката на случай непредвиденных обстоятельств) работать на заброшенной платформе, если они не смогут обновить всю свою систему до .NET Core (риск что может помешать рассмотрению попыток миграции) это также лишает их возможности участвовать в будущей модели разработки ASP.NET Core, если они не могут перенести свои существующие системы, над которыми они работают изо дня в день, что приведет к возможно только в том случае, если он будет пользоваться той же поддержкой, что и WebForms, что, я надеюсь, все еще рассматривается.

Никто не упомянул: в нашем базовом приложении asp.net нам нужно размещать службы WCF, и это единственная проблема для перехода с .NET Framework. К сожалению, я не вижу новостей о поддержке wcf на стороне сервера в .net core 3.

@DamianEdwards @davidfowl @natemcmaster Мы в одной лодке. У моей компании есть ряд продуктов, которые работают на ASP.Net Core на платформе .Net Full, и мы поддерживаем их гораздо дольше, чем 3 года, из-за того, как медленно меняются отрасли, которые мы продаем. Расширение LTS для .net core 2.2 было бы бессмысленным в нашей ситуации, потому что нам пришлось бы переносить наши основные приложения ASP.net обратно на ASP.Net. Конечно, это поражение, ребята! Не могли бы вы просто предложить поддержку приложений на более короткие периоды времени? К сожалению, это также то, что мы не можем контролировать. Отрасли, в которых мы работаем, может занять год только на то, чтобы внедрить наше новое программное обеспечение.

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

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

Очень хотелось бы получить ответ от команды .net по этому поводу.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Да ладно, это просто заставляет ваши библиотеки быть лучше наслоены 😉

Разве этот аргумент не работает в обратном направлении?

Я не могу понять, что на самом деле мешает вам правильно распределить уровни архитектуры ASP.NET Core?
Итак, да, некоторые функции времени выполнения недоступны в .Net Framework, например Span<T> , но это не означает, что они вообще недоступны. Он доступен , но не такой производительный, как на ядре .Net. Мы могли бы с этим справиться.

Некоторые низкоуровневые реализации могут быть реализованы в вариациях специально для ядра .net и стандарта .net. И я сомневаюсь, что для этого есть много места, поскольку API-интерфейсы обычно доступны в виде пакетов NuGet.
Многие авторы библиотек поддерживают разные реализации для разных платформ, так было всегда.

Не могли бы вы уточнить, что именно мешает вам поддерживать .Net Framework / .Net Standard. Несколько простых примеров того, что нельзя абстрагировать, чтобы иметь платформенно-зависимые реализации?

мешает вам поддерживать .Net Framework / .Net Standard. Несколько простых примеров того, что нельзя абстрагировать, чтобы иметь платформенно-зависимые реализации?

Сверху в голове, элементы, требующие изменений во время выполнения или фреймворка

• Указатели внутреннего сборщика мусора; поэтому создание безопасного диапазона только из ссылки без объекта: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Реализации интерфейса по умолчанию
• Пользовательские рабочие элементы Threadpool
• Перегрузки диапазона для базовых типов: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable перегружает базовые типы: Stream, Sockets, TextReader / TextWriter, WebSockets и т. Д.
• IAsyncEnumeratorперегрузки по базовым типам: Stream, Sockets, TextReader / TextWriter, WebSockets и т. д.

Бонусные предметы

• Встроенное оборудование (x86, x64, ARM)
• Анализ выхода (новые выделения в стек)
• Параллельные версии среды выполнения
• Исправление переадресации привязки и управления версиями

Я не понимаю, почему мы не можем просто иметь версию netstandard, которая больше не поддерживает netframework. Точно так же, как Windows Phone не имеет поддержки netstandard, кроме 1.2. Почему мы не можем продвинуть стандарт вперед и позволить таким реализациям, как netcore, mono, xamarin и т.д., в конечном итоге или никогда не соответствовать ему. Затем разработчик библиотеки должен решить, какую версию netstandard они хотят реализовать, чтобы максимально расширить охват.

Это изменение делает так, что xamarin и mono больше не могут использовать aspnetcore. Это делает так, что производители библиотек вынуждены нацеливаться как на netcore, так и на netstandard, или, что еще хуже, отказываться от netstandard полностью и нацеливаться только на netcore.

Это в конечном итоге приведет к смерти netstandard.

мешает вам поддерживать .Net Framework / .Net Standard. Несколько простых примеров того, что нельзя абстрагировать, чтобы иметь платформенно-зависимые реализации?

Сверху в голове, элементы, требующие изменений во время выполнения или фреймворка

• Указатели внутреннего сборщика мусора; поэтому создание безопасного диапазона только из ссылки без объекта: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Реализации интерфейса по умолчанию
• Пользовательские рабочие элементы Threadpool
• Перегрузки диапазона для базовых типов: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable перегружает базовые типы: Stream, Sockets, TextReader / TextWriter, WebSockets и т. Д.
• IAsyncEnumerator перегружает базовые типы: Stream, Sockets, TextReader / TextWriter, WebSockets и т. Д.

Бонусные предметы

• Встроенное оборудование (x86, x64, ARM)
• Анализ выхода (новые выделения в стек)
• Параллельные версии среды выполнения
• Исправление переадресации привязки и управления версиями

Пункты в этом первом списке звучат как вещи, которые можно было бы изменить в netstandard?

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

В то же время, похоже, что Microsoft не хочет продвигать вперед версию .NET Standard, которая навсегда несовместима с .NET Framework. В противном случае это не было бы проблемой - просто продвигайтесь вперед с netstandard30 или netstandard40 и откажитесь от поддержки Framework; и поставьте .NET Core на один из этих новых стандартов.

Я чувствую, что эта тема и т. Д. Является результатом того, что Microsoft эффективно загоняет себя в угол.

В то же время, похоже, что Microsoft не хочет продвигать вперед версию .NET Standard, которая навсегда несовместима с .NET Framework.

Это неискренне; .NET Standard 2.1 находится на стадии завершения и имеет 3104 новых API по сравнению с .NET Standard 2.0, включая Span перегрузки для базовых типов каркасов; что может сделать его несовместимым с .NET Framework.

.NET Standard все еще движется вперед.

В противном случае это не было бы проблемой - просто продвигайте netstandard30 или netstandard40 и откажитесь от поддержки Framework; и поставьте .NET Core на один из этих новых стандартов.

Проблема в том, что каждая среда выполнения, а не только Framework, несовместима с одним из новых стандартов; а затем несовместим с каждым стандартом после этого. То, что входит в .NET Standard, должно быть согласовано различными средами выполнения как вещи, которые могут быть реализованы.

Будут ли в ближайшее время поддерживать внутренние указатели в Mono и Unity? Если их не добавить в .NET Standard, они будут заблокированы из этого .NET Standard в любом будущем .NET Standard до тех пор, пока их GC не будут изменены для работы с ними. Тем не мение; Лучше добавить API, который они могут реализовать сейчас, и сохранить те, которые они не могут, для будущего стандарта.

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

Некоторые API-интерфейсы Core 2.1 были изменены между предварительным просмотром 1 и предварительным просмотром 2 (из-за отзывов пользователей); так что трудно даже знать, какие API являются новыми в Core X, пока он не будет выпущен, и в этот момент он высечен в камне. Затем, какие из них являются правильным набором для добавления в Стандарт для всех сред выполнения, которые необходимо реализовать (или оставить позади).

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

Было бы хорошо, если бы новый .NET Standard мог поставляться одновременно с .NET Core, и все среды выполнения могли бы мгновенно реализовать его, а затем ASP.NET Core мог бы использовать все новые API через .NET Standard; но в идеале он хорош, но не практичен. Есть даже несколько утвержденных API, которые не были реализованы в .NET Core.

Основной вопрос заключается в том, может ли ASP.NET Core использовать запрошенные API и поставляться в версии .NET Core, которая поставляется вместе с ним (поскольку они поставляются одновременно); или он может использовать только API-интерфейсы, которые поставлялись в предыдущей версии .NET Core - которые, следовательно, имеют шанс быть в версии .NET Standard для этого .NET Core? (Поскольку это похоже на то, что версии .NET Standard будут отставать в версии apis 1 от .NET Core в настоящее время; с использованием размера выборки 1)

Если ASP.NET Core может использовать API; затем API проходят тестирование на использование и оцениваются, являются ли они хорошими API; если нет, то можно предложить лучший API. Если ASP.NET Core не может их использовать, то, являются ли они хорошими API-интерфейсами, пока неизвестно, когда они станут кандидатами в .NET Standard.

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

.NET Core, поддерживая традиционные рабочие нагрузки .NET Framework (включая WinForms и WPF), по сути, является обновлением CLR; но сделать это более устойчивым и ориентированным на будущее образом?

Это неискренне; .NET Standard 2.1 находится на стадии завершения и имеет 3104 новых API по сравнению с .NET Standard 2.0, включая перегрузки Span для базовых типов фреймворков; что может сделать его несовместимым с .NET Framework.

Включая .NET Framework 4.8 и .NET Framework 4.9?

Всегда есть вероятность, что в будущих обновлениях Framework появятся эти новые API. На данный момент кажется очевидным, что .NET Framework никогда не получит DIM, следовательно, любой интерфейс с методом DIM не может быть портирован на .NET Framework.

.NET Core, поддерживая традиционные рабочие нагрузки .NET Framework (включая WinForms и WPF), по сути, является обновлением CLR; но сделать это более устойчивым и ориентированным на будущее образом?

И не обратное доказательство. Как бы Microsoft ни демонстрировала такие вещи, как Paint.Net, работающая на .NET Core, я не могу запускать свои существующие серверные проекты на .NET Core, как и большинство людей.

Было бы хорошо, если бы новый .NET Standard мог поставляться одновременно с .NET Core, и все среды выполнения могли бы мгновенно реализовать его, а затем ASP.NET Core мог бы использовать все новые API через .NET Standard; но в идеале он хорош, но не практичен.

Это также может быть непрактичным, но я думаю, что люди в целом были бы немного счастливее, если бы могли быть две версии ASP.NET Core:

• Быстро развивающаяся передовая версия, привязанная к .NET _Core_ и способная использовать любой новый API, какой пожелает.
• Более медленная версия LTS, привязанная к .NET _Standard_ и работающая в большем количестве мест; который в конечном итоге догоняет старые передовые сборки, но всегда отстает.

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

• Быстро развивающаяся передовая версия, привязанная к .NET Core и способная использовать любой новый API, какой пожелает.
• Более медленная версия LTS, привязанная к .NET Standard и работающая в большем количестве мест; который в конечном итоге догоняет старые передовые сборки, но всегда отстает.

Итак, если бы ASP.NET Core 3.0 вышел только как .NET Core 3.0; но позже, когда это был стандарт .NET с API-интерфейсом; были выпущены пакеты для ASP.NET Core 3.x, которые также были .NET Standard (даже если ASP.NET Core перешел на 4.0); это отвечало бы вашим требованиям?

@ yaakov-h

Более медленная версия LTS, привязанная к .NET Standard и работающая в большем количестве мест; который в конечном итоге догоняет старые передовые сборки, но всегда отстает.

Что это значит? Вы всегда можете использовать ASP.NET Core 2.1 с расширенной поддержкой, о которой упоминал

Вы всегда можете использовать ASP.NET Core 2.1 с расширенной поддержкой, которая

Пожалуйста, не раскалывайте сообщество !!
(на основе голосования) Ожидаете ли вы, что 1/3 разработчиков останется в asp.net core 2.1? или ожидать разработчиков 2/3, которые создают пакеты nuget, которые должны поддерживать 2 версии своей библиотеки?

@benaadams

Итак, если бы ASP.NET Core 3.0 вышел только как .NET Core 3.0; но позже, когда это был стандарт .NET с API-интерфейсом; были выпущены пакеты для ASP.NET Core 3.x, которые также были .NET Standard (даже если ASP.NET Core перешел на 4.0); это отвечало бы вашим требованиям?

Точно.

@davidfowl

Вы всегда можете использовать ASP.NET Core 2.1 с расширенной поддержкой, о которой упоминал

Кажется, здесь есть противоречивые сообщения:

1. Нормально оставаться на 2.1, более старой версии LTS
2. ASP.NET Core развивается так быстро, что мы не можем даже дождаться одного цикла выпуска между .NET Core и последующим .NET Standard.

Я думаю, что (2) вызывает много путаницы и страха остаться позади.

@ John0King

(на основе голосования) Ожидаете ли вы, что 1/3 разработчиков останется в asp.net core 2.1? или ожидать разработчиков 2/3, которые создают пакеты nuget, которые должны поддерживать 2 версии своей библиотеки?

Я ожидаю, что авторы библиотеки решат, какая минимальная версия ASP.NET Core, которую они хотят поддерживать, и нацелятся на нее. Это то, что они уже делают сегодня. Некоторые библиотеки поддерживают ASP.NET Core 1.x и 2.x, некоторые поддерживают только 2.x. Это ничем не отличается.

@ yaakov-h

Я не совсем понимаю, в чем заключаются противоречивые сообщения. Текущая версия 2.1 является LTS и работает на .NET Core и .NET Framework и поддерживается в течение 3 лет. Это не новое сообщение, это то же сообщение, что и у нас с самого начала.

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

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

Любой ответ от команды ms?

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

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

Очень хотелось бы получить ответ от команды .net по этому поводу.

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

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

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

@davidfowl

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

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

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

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

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

ASP.NET Core 2.1 уже разработан, усилия по запуску ASP.NET Core на FX / .NET Core - это уже вложенные безвозвратные затраты. Таким образом, решение должно быть сформулировано как вопрос ресурсов MS для поддержки уже разработанной платформы (после LTS) по сравнению с совокупными затратами, недоброжелательностью и инерцией, сгенерированными для отказа от популярной платформы.

Я не уверен, что понимаю, о чем тогда просят. Жизненный цикл LTS не изменился с момента выхода 2.1. Если бы вы написали приложение на LTS-версии, будь то .NET Core или .NET Framework, прошло бы 3 года, прежде чем вы перестанете «поддерживать». Я не совсем понимаю, как вытаскивают коврик из-под вас с точки зрения поддержки, это не изменилось. Вам нужно будет выполнить обновление, чтобы получать обновления платформы.

Теперь я понимаю, что 2.1, являющаяся последней версией LTS, поддерживаемой в .NET Framework, означает, что нет места для обновления, но здесь появляется расширенная поддержка LTS. Если приложение никогда не сможет перейти на .NET Core даже по прошествии этих 6 лет, потому что API-интерфейсы отсутствует, пожалуйста, сообщите о проблемах, чтобы мы понимали пробелы.

Я не уверен, что понимаю, о чем тогда просят.

Этот поток запрашивает у MS различные уровни обязательств, начиная от: продолжать разрабатывать его в тандеме с .NET Core, разрабатывать его «медленным поездом», не отказываясь от ASP.NET Core 2.1 и поддерживать тот же уровень поддержки, что и WebForms, расширять LTS. . Я бы предпочел не отказываться от него в качестве варианта хостинга для ASP.NET Core (отредактируйте: obv все, что выше, что было бы более предпочтительным), который не сдерживал бы .NET Core только v3 +, предоставляя при этом много полезности для существующего .NET. Валютные инвестиции.

Теперь я понимаю, что 2.1, являющаяся последней версией LTS, поддерживаемой .NET Framework, означает, что нет места для обновления до

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

• Любой, кто думал об использовании его в качестве промежуточной платформы для перехода на .NET Core, стал менее осуществимым вариантом, поскольку они сталкиваются с риском оказаться застрявшим на неподдерживаемой платформе, если миграция займет больше времени, чем ожидалось, или они столкнутся с препятствиями, если какая-либо из зависимостей они полагаются, что не могут работать на .NET Core.
• Любой, кто вынужден использовать серверы .NET Framework существующей управляемой инфраструктуры своего предприятия, не может участвовать в использовании новой модели разработки и экосистемы и должен видеть, что их существующие классические знания / навыки ASP.NET становятся менее ценными с каждым днем.
• Команды не могут перенести свои существующие системы, необходимые для .NET Framework, и потребуют переключения контекста на новые проекты ASP.NET Core на .NET Core.
• Ни одна организация не хочет быть принужденной к незапланированной миграции, потому что изменились рекомендации, на которые они опирались при формировании своего бюджета, планирования и инвестиционных решений.

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

В идеальном мире все были бы на .NET Core, но существуют значительные инвестиции в .NET FX, которые обесцениваются из-за этого решения.

Если приложение никогда не сможет перейти на .NET Core даже по прошествии этих 6 лет из-за отсутствия API,

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

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

Спасибо за то, что убили .NET Standard такими решениями.

До сих пор мы игнорировали .NET Core, потому что существует множество сторонних сборок, которые еще не нацелены на Core.

Многие поставщики, желающие поддерживать Core, делают это наполовину, например, управляемый ODP.NET без собственных API-интерфейсов, которые доступны только в .NET Framework.

Затем вы приходите с такими решениями.

Нет, мы не будем внедрять .NET Core быстрее только потому, что для Microsoft слишком много работы по поддержке .NET Framework, и она не может предоставить .NET Standard, который вы, ребята, начали использовать.

@davidfowl Я могу привести два примера того, что затрудняет переход на .NET Core - WCF (многие существующие корпоративные приложения используют его, я считаю, что другие уже поднимали эту проблему) и отсутствие библиотеки Adomd в .NET Core / NET Стандартный (это для связи с SSAS, также используется в корпоративных приложениях, отслеживается в SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Некоторые другие (winforms) должны быть исправлены с помощью пакета совместимости .net core 3 (ура!) - нам нужно подождать и посмотреть, как это действительно работает.

@mythz

Этот поток запрашивает у MS различные уровни обязательств, начиная от: продолжать разрабатывать его в тандеме с .NET Core, разрабатывать его «медленным поездом», не отказываясь от ASP.NET Core 2.1 и поддерживать тот же уровень поддержки, что и WebForms, расширять LTS. . Я бы предпочел не отказываться от него как от варианта хостинга для ASP.NET Core, который не сдерживал бы .NET Core только v3 +, но в то же время предоставлял бы много полезности для существующих инвестиций .NET FX.

Что ж, в настоящее время мы изучаем расширение поддержки LTS, но мы не рассматриваем возможность поддержки первоклассной .NET Framework для ASP.NET Core навсегда (о чем вы и просите). Эта версия ASP.NET Core, которая требует того же уровня поддержки, что и WebForms, когда-либо получит только исправления безопасности и исправления надежности. Я могу гарантировать вам, что по мере появления функций в более новых версиях ASP.NET Core уровень удовлетворенности тех, кто использует ASP.NET Core 2.1, будет снижаться (по крайней мере, так мне подсказывает моя интуиция), поскольку эти изменения все еще не будут достичь.

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

Это очень распространено (даже в Microsoft), поэтому мы добавили эту возможность ссылаться на библиотеки DLL .NET Framework в .NET Core 2.0, потому что оказалось, что большинство сборок совместимы, даже если они не были скомпилированы для .NET Core. Теперь есть некоторые вещи, которые никогда не будут работать (например, домены приложений ...), но я ожидаю, что по мере добавления дополнительной поверхности API набор библиотек, которые просто не работают, уменьшится до незначительного числа.

@pjmlp

Я не понимаю, как это убивает .NET Standard. .NET Standard намного больше, чем ASP.NET Core. Речь идет о создании повторно используемых общих библиотек (например, Microsoft.Extensions *), которые работают на любой поддерживающей платформе .NET.

До сих пор мы игнорировали .NET Core, потому что существует множество сторонних сборок, которые еще не нацелены на Core.

Какие? Есть ли поддержка для тех, кто уже в пути, или эти сборки никогда не будут поддерживать .NET Core?

Многие поставщики, желающие поддерживать Core, делают это наполовину, например, управляемый ODP.NET без собственных API-интерфейсов, которые доступны только в .NET Framework.

Я согласен с этим и видел массу урезанных версий библиотек на .NET Core (даже с некоторыми библиотеками, которые поставляет Microsoft), но я бы сказал, что ситуация меняется к лучшему. Некоторые из причин этого заключались в том, что изначально отсутствовал набор API-интерфейсов, которые существовали в .NET Core 1.0. В версиях 2.0 и 2.1 мы увидели, что большой набор библиотек легче переносится на ядро ​​/ стандарт без особой потери функциональности.

@voltcode Спасибо за конкретный отзыв! Мы ожидаем, что некоторые из этих проблем совместимости исчезнут или станут минимальными в течение периода времени, в течение которого мы поддерживаем проекты .NET Core сегодня (около 3 лет).

@davidfowl

....

До сих пор мы игнорировали .NET Core, потому что существует множество сторонних сборок, которые еще не нацелены на Core.

Какие? Есть ли поддержка для тех, кто уже в пути, или эти сборки никогда не будут поддерживать .NET Core?

В нашем случае ODP.NET является очевидным, поскольку Oracle не переносит 100% функций драйвера в Core.

Многие поставщики, желающие поддерживать Core, делают это наполовину, например, управляемый ODP.NET без собственных API-интерфейсов, которые доступны только в .NET Framework.

Я согласен с этим и видел массу урезанных версий библиотек на .NET Core (даже с некоторыми библиотеками, которые поставляет Microsoft), но я бы сказал, что ситуация меняется к лучшему. Некоторые из причин этого заключались в том, что изначально отсутствовал набор API-интерфейсов, которые существовали в .NET Core 1.0. В версиях 2.0 и 2.1 мы увидели, что большой набор библиотек легче переносится на ядро ​​/ стандарт без особой потери функциональности.

Однако многие наши клиенты это не видят.

Просто для того, чтобы вы почувствовали, как такого рода решения повлияют на будущее .NET, в недавнем проекте заказчик оплатил усилия по разработке, чтобы переместить приложение с .NET Framework на Java для развертывания UNIX, поскольку он не хотел Сделайте ставку на .NET Core и урезанную реализацию ODP.NET, в то время как драйвер JDBC предлагает 1: 1 паритет функций с драйвером .NET Framework ODP.NET.

Другие также могут выбрать другие альтернативные стеки.

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

Эта проблема всплыла наверху HN. Вы, ребята (@MSFT), возможно, тоже захотите проверить там. Всего 1 час и уже 50+ комментариев.

@davidfowl

Я не понимаю, как это убивает .NET Standard. .NET Standard намного больше, чем ASP.NET Core. Речь идет о создании повторно используемых общих библиотек (например, Microsoft.Extensions *), которые работают на любой поддерживающей платформе .NET.

Я не понимаю, что такое ASP.NET Core, если не повторно используемая разделяемая библиотека? Если тенденция к тому, чтобы библиотеки были современными и быстрыми, заключалась в отказе от поддержки .NET Standard, это непростой вопрос. Следует ли Newtonsoft.Json переключаться только на .NET Core 3, если он может работать намного быстрее? Стоит ли Autofac?

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

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

AspNetCore было удивительно для нашего стека с точки зрения самостоятельного хостинга (http.sys) веб - API и статического веб - контента вокруг различных услуг. Мы пришли из Нэнси, что было солидно, но с нашей точки зрения также было много недостатков, поэтому около года назад мы перешли на AspNetCore. Сегодня мы запускаем каждую из наших кодовых баз на 2.x. Во многих случаях мы вполне могли бы перейти на чистую цель .NET Core. Но есть также много сервисов, которые мы создали для использования AspNetCore, которые также полагаются на такие вещи, как System.DirectoryServices и System.Drawing . С точки зрения этих услуг, мы изменили бы технологию веб-хостинга до того, как уйдем с .Net Framework. К сожалению, из-за сложности одновременного управления двумя различными технологиями веб-хостинга и размера нашей команды мы, вероятно, также полностью исключим AspNetCore из остальных наших сервисов в пользу чего-то более совместимого для обеих целей.

Короче говоря - это решение заставит нас полностью отказаться от AspNetCore в какой-то момент в будущем (вероятно, когда LTS истечет для 2.x), чего я не знаю прямо сейчас. Если до этого дойдет, мы, скорее всего, напишем собственное решение для замены AspNetCore, поскольку наши варианты использования с точки зрения фактического количества используемых функций AspNetCore довольно узкие (при этом возможности, которые мы используем _do_ огромная добавленная стоимость для нас сегодня).

Другие также могут выбрать другие альтернативные стеки.

Это справедливо, но у альтернативных стеков такая же политика поддержки. Java перешла на аналогичную модель LTS (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

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

@bencyoung

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

Я не понимаю, что такое ASP.NET Core, если не повторно используемая разделяемая библиотека? Если тенденция к тому, чтобы библиотеки были современными и быстрыми, заключалась в отказе от поддержки .NET Standard, это непростой вопрос. Следует ли Newtonsoft.Json переключаться только на .NET Core 3, если он может работать намного быстрее? Стоит ли Autofac?

Не понимаю, насколько это сложно. Я на 97% уверен, что эти библиотеки не удалят фреймворки, потому что их клиенты будут жаловаться. Планка для удаления фреймворков чрезвычайно высока, и по этой же причине мы сохранили Microsoft.Extensions. * В .NET Standard 2.0. Я согласен, что было бы нечетко, если бы мы все туда переместили, но здесь происходит не это.

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

@robkeimig

Но есть также много сервисов, которые мы создали для использования AspNetCore, которые также полагаются на такие вещи, как System.DirectoryServices и System.Drawing.

Они существуют в компактном пакете Windows на .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Короче говоря - это решение заставит нас полностью отказаться от AspNetCore в какой-то момент в будущем (вероятно, когда LTS истечет для 2.x), чего я не знаю прямо сейчас. Если до этого дойдет, мы, скорее всего, напишем собственное решение для замены AspNetCore, поскольку наши варианты использования с точки зрения фактического количества используемых функций AspNetCore довольно узкие (при этом функции, которые мы используем, предоставляют огромная добавленная стоимость для нас сегодня).

Было бы так, если бы поддержка была расширена?

Кроме того, теперь нам придется сначала отсечь все другие неподдерживаемые технологии (домены приложений, удаленное взаимодействие и т. Д.), Вместо того, чтобы иметь возможность выполнять эту работу параллельно или на более позднем этапе.

Почему вы не можете сначала перейти на 2.1?

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

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

Конечно, именно поэтому мы предлагаем расширенную поддержку, как упоминал @DamianEdwards .

Просто чтобы показать, какие последствия вызывает это решение - а как же Blazor? Перестанет ли он основываться на netstandard? Стоит ли нам этого ожидать? Blazor рекламируется как следующая большая вещь. Что еще из github.com/aspnet, которое в настоящее время зависит от netstandard, откажется от него и перейдет на ядро ​​net в следующем крупном выпуске? Каковы планы в отношении других вещей, находящихся под контролем MSFT, но вне репозитория aspnet, которые разделят судьбу aspnetcore?

@davidfowl

Другие также могут выбрать другие альтернативные стеки.

Это справедливо, но у альтернативных стеков такая же политика поддержки. Java перешла на аналогичную модель LTS (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

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

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

Теперь мне интересно, настраиваю ли я нас на много боли позже.

Здесь много взаимосвязанных проблем. Вы говорите, что ядро ​​ASP.Net никогда не предназначалось для работы только на .NET Framework. Сообщения Microsoft об ASP.Net Core в прошлом не могли прояснить это.

Точно так же многие разработчики .NET привыкли к мысли, что .NET Framework является основной реализацией, а остальные обычно являются подмножествами, за исключением, конечно, API, специфичных для среды. Это изменилось с появлением .NET Core, но у многих людей в целом сложилось впечатление, что «полная» .NET Framework в конечном итоге будет поддерживать все, что делает почти .NET Core (за исключением инструментов и кроссплатформенной совместимости, очевидно), но просто в более медленном масштабе времени, ожидая устранения изломов, прежде чем включать их.

Недавно было много предположений о том, что некоторые действительно важные функции могут никогда не попасть в .NET Framework. (например, что риски совместимости диапазонаtype, который считается слишком серьезным для реализации в .NET Framework 4.8, предполагает, что они, возможно, никогда не будут реализованы, поскольку почему эти риски будут ниже в 4.9 ?. Подобные проблемы, очевидно, связаны с методами интерфейса по умолчанию.) Это серьезный сдвиг парадигмы, который не понравится многим разработчикам!

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

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

Это действительно раздражает. .NET Core имеет некоторые проблемы, которые делают его менее оптимальным для некоторых корпоративных приложений. Конечно, его можно использовать в приложениях, которые постоянно развиваются. Но, например, на большинстве предприятий также есть некоторые приложения, которые развертываются и используются только раз в несколько лет. Это плохо работает с .NET Core. Здесь предприятиям приходится бороться с короткими циклами поддержки для большинства выпусков. А в Windows в настоящее время не существует механизма для автоматической установки новых выпусков исправлений для получения обновлений безопасности и т. Д.

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

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

@davidfowl

Но есть также много сервисов, которые мы создали для использования AspNetCore, которые также полагаются на такие вещи, как System.DirectoryServices и System.Drawing.

Они существуют в компактном пакете Windows на .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Я не знал, что пакет совместимости поддерживает этот вариант использования. В идеале мы хотели бы перенести все на .NET Core, и это выглядит действительно хорошим ответом (который мы, возможно, изначально упустили). У нас нет планов переносить хостинг наших сервисов на Linux / OSX, поэтому эти части могли бы нам хорошо сочетаться.

Было бы так, если бы поддержка была расширена?

Что касается поддержки - я считаю, что LTS 2.x до 2021 года является разумным, учитывая все другие ограничения, которые связаны с чем-то столь далеко идущим.

Основываясь на том, что я сейчас понимаю, мы, вероятно, почувствуем себя комфортно при обновлении до AspNetCore 3.x, как только у нас будет возможность просмотреть и преобразовать проекты .NET Framework в проекты .NET Core (с использованием пакета совместимости по мере необходимости).

Спасибо за ваше обращение.

Я писал на .NET (в основном на C #) в течение 15 лет в проектах высокого давления. Я потратил впустую столько лет и денег клиентов, тратя время на чрезмерно спроектированную структуру. Мне понравилась концепция .NET Core. Для меня это была скорость написания проектов NodeJS, но в потрясающей экосистеме .NET (включая весь жир). К сожалению, это обещание не выполнено, оно все еще (даже с учетом этого нового объявления) слишком сложно для кровавого использования. Последние 3 года я строил на NodeJS, извините, ребята, просто не сравнить. Сделайте его более простым и легким в использовании, и вы снова привлечете широкое сообщество разработчиков.

Для проектов с жесткими, скомпилированными двоичными зависимостями .NET Framework (материалы поставщика без исходного кода), которые могут работать в приложениях ASP.NET Core 2.1, нацеленных на .NET Framework, развернутых в Windows, в проект будет добавлен Windows Compatibility Pack, чтобы они продолжали работать. Ядро 3.0, если жесткие зависимости ссылочных типов поставляются пакетом?

Существует огромная экосистема чрезвычайно зрелых коммерческих библиотек, которые, к сожалению, зависят от System.Drawing, GDI, а иногда и от реестра (!). Если они будут работать только сейчас с 2.1 и поддерживаться только в течение трех лет, это может помешать внедрению Core на некоторых предприятиях.

.NET Core делает полный круг, чтобы достичь отправной точки.

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

@davidfowl

ASP.NET Core, работающий на .NET Framework, никогда не предназначался для постоянного использования, он всегда был ступенькой

Это совсем не так. Обмен сообщениями в ASP.NET Core всегда заключался в том, что он поддерживается как в .NET Core, так и в .NET Framework. Даже в самых ранних анонсах .NET Core упоминаются обе платформы для ASP.NET Core (тогда еще ASP.NET 5).

Очень известный образ, демонстрирующий .NET Standard, также включает ASP.NET Core, охватывающий как Core, так и всю структуру. А в официальной документации даже говорится: «Нет планов по отказу от поддержки таргетинга .NET Framework в ASP.NET Core».

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

это даже называется ASP.NET Core

Да ладно тебе. Спустя все это время людям вроде меня приходилось бороться с людьми за разделение .NET Core и ASP.NET Core, потому что это не одно и то же, не используйте здесь одно и то же имя в своих интересах. Это просто нечестно. Изменение названия на «Core» определенно не связано с явной привязкой его к .NET Core. Кроме того, у EF Core есть «ядро», но он будет продолжать работать в netstandard, поэтому этот аргумент не работает.

вот где появляется расширенная поддержка LTS. Если приложение никогда не сможет перейти на .NET Core даже по прошествии этих 6 лет […]

Откуда это вообще взялось? В прошлый раз сообщение все еще было «мы исследуем предложение LTS с расширенной поддержкой» . Это реально сейчас, и у нас есть 6 лет?

@pjmlp

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

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

@KevinCathcart

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

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

См. Https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Для проектов с жесткими, скомпилированными двоичными зависимостями .NET Framework (материалы поставщика без исходного кода), которые могут работать в приложениях ASP.NET Core 2.1, нацеленных на .NET Framework, развернутых в Windows, в проект будет добавлен Windows Compatibility Pack, чтобы они продолжали работать. Ядро 3.0, если жесткие зависимости ссылочных типов поставляются пакетом?

Да, он бинарно совместим.

Существует огромная экосистема чрезвычайно зрелых коммерческих библиотек, которые, к сожалению, зависят от System.Drawing, GDI, а иногда и от реестра (!). Если они будут работать только сейчас с 2.1 и поддерживаться только в течение трех лет, это может помешать внедрению Core на некоторых предприятиях.

Как я уже упоминал несколько раз в этой теме. Мы добавили возможность напрямую ссылаться на зависимости, скомпилированные для .NET Framework, в проектах .NET Core.

@poke Вы правы насчет обмена сообщениями, это было не совсем понятно, моя ошибка.

Откуда это вообще взялось? В прошлый раз сообщение все еще было «мы исследуем предложение LTS с расширенной поддержкой». Это реально сейчас, и у нас есть 6 лет?

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

.NET Core всегда собирался заменить .NET Framework (изначально это должна была быть .NET Framework 5), но переписывание было настолько амбициозным, что теперь его использовали для поддержки настольных приложений.

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

ожидать

@edandersen , вы запускали ApiPort на этих внешних dll? Он покажет вам, используют ли они какие-либо API-интерфейсы, которые недоступны в .NET Core. Если он использует только доступные API, это не должно быть проблемой, в противном случае знание того, какие API отсутствуют, помогает обсуждению и расстановке приоритетов функций.
Пакет совместимости с Windows уже предоставляет функции для system.drawing и реестра. Вы уже пробовали запускать эти вещи на .NET Core? System.Drawing работает даже на * nix с использованием моно libgdiplus. Это позволяет нам использовать ClosedXML в системах, отличных от Windows, для работы с файлами Excel.

Самая большая зависимость .NET Framework для «недавних» приложений в нашей компании - это функциональность WCF.
Клиентские библиотеки .NET Core WCF улучшаются. Я не проверял, насколько хорошо они работают с некоторыми услугами, которые мы потребляем, но в прошлом мы не могли поговорить с некоторыми службами. Но недостающая функциональность уже была в их списке проблем. С другой стороны, простые сервисы работают хорошо!
С другой стороны, в .NET Core нет «простой» замены для размещения служб SOAP. Это заблокировало бы перенос некоторых приложений на .NET Core (но, как уже упоминалось, в этом нет необходимости).
Для недавнего приложения ASP.NET Core мы создали дополнительное веб-приложение прокси ASP.NET, которое просто размещает службу WCF, а затем перенаправляет в приложение ASP.NET Core через HTTP / JSON. Не очень красиво и усложняет развертывание, но допускает некоторые точки интеграции.

Я не говорю, что мне действительно нужна возможность хостинга WCF в .NET Core, учитывая, что у меня возникают головные боли при его настройке. Хотя какой-то вариант размещения служб SOAP и генерации WSDL был бы крутым. Я видел, как несколько библиотек OSS уже пытались это сделать. Может, этого будет достаточно.

@ davidfowl

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

Дело в том, что, хотя версиям Java LTS тоже три года, совместимость всех основных реализаций - это золото, что вы, ребята, готовы выбросить из окна.

Вся эта ошибка .NET Framework, .NET Core, Xamarin, .NET Standard начинает выглядеть как старые добрые времена WinDev vs DevTools, только внутри .NET-команд для разнообразия.

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

Эти решения не внушают доверия.

Это действительно похоже на ошибку со стороны команды .NET, особенно в контексте текущего климата!

Для тех, кто упоминает Java, вы действительно смотрели, что там происходит в последнее время? В период безумного судебного процесса против Google за его использование в Android и последних махинаций с лицензированием, поведение Oracle неизменно похоже на поведение компании, которая хочет избавиться от нежелательного продукта, а не того, кто хочет, чтобы он процветал!

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

@masonwheeler

Мы, работающие в обеих средах, действительно ценим работу Oracle
делал с Java.

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

Что касается Android, то я полностью поддерживаю иск, поскольку Google
удалось форк платформы Java, тем самым преуспев там, где Microsoft потерпела неудачу
с J ++. По-прежнему с нетерпением ждем того дня, когда любой случайный JAR в Maven Central будет действительно работать на Android.

Что касается .NET, мне уже надоели постоянные перезагрузки
как мы должны ориентироваться на платформы Microsoft.

Весь WinRT, UAP, UWP, .NET Native отбрасывает F #, XNA, Core 1.0.
много кислого винограда, и это недавнее решение не улучшает ситуацию
в целом.

.NET - моя любимая платформа, поэтому, пожалуйста, не портите ее еще больше.

@mythz

Теперь я понимаю, что 2.1, являющаяся последней версией LTS, поддерживаемой .NET Framework, означает, что нет места для обновления до

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

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

В основной поддержке LTS можно ожидать только двух вещей:

• Исправления безопасности
• Критические исправления

Большинство первых (исправлений безопасности) будут исправлены через Центр обновления Windows (поскольку вы нацелены на .NET Framework). Таким образом, остались только исправления безопасности и критических ошибок, которые есть в самом ASP.NET Core.

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

Это просто оставляет открытыми ошибки безопасности, которые разумно устранить с помощью LTS.

В предыдущих ответах я видел упоминание TLS 1.4 и т. Д., Они в любом случае не будут охватываться LTS, поскольку это новая функция, которая в любом случае одинакова даже для Java (Java 6 имеет только поддержку TLS 1.0 - TLS 1.1, если вы считаете в закрытые обновления доступны только подписчикам расширенной поддержки Oracle).

• Любой, кто думал об использовании его в качестве промежуточной платформы для перехода на .NET Core, стал менее осуществимым вариантом, поскольку они сталкиваются с риском оказаться застрявшим на неподдерживаемой платформе, если миграция займет больше времени, чем ожидалось, или они столкнутся с препятствиями, если какая-либо из зависимостей они полагаются, что не могут работать на .NET Core.
  Но какие API-интерфейсы отсутствуют, которые теперь можно использовать с ASP.NET Core на .NET Framework, но нельзя использовать с ASP.NET Core на .NET Framework + Пакеты совместимости?

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

Начиная с .NET Core, вы можете ссылаться (и использовать) любую библиотеку .NET Framework в проекте .NET Core, если она использует только API-интерфейсы, доступные в .NET Standard или .NET Core .

Это не требует, чтобы автор библиотеки обновлял свои библиотеки для таргетинга на netstandard / netcoreapp.

Может быть, было бы полезно, если бы Microsoft расширила веб-страницу / библиотеку NuGet с помощью функции / ссылки рядом с каждым пакетом nuget на nuget.org, который показывает отчет, если эта библиотека использует какие-либо несовместимые API-интерфейсы, недоступные в определенных версиях .NET Core?

Например

'Company.Example.MyLib` покажет

• .NET Core 2.1: частичная поддержка (подробный отчет) - где в подробном отчете будут показаны Apis, которые работают, а какие нет.
• .NET Core 3.0 :; полностью поддерживается

Это должно быть возможно при запуске анализатора переносимости .NET? Бонусом будет, если он добавит список общедоступных API-интерфейсов, которые можно безопасно вызывать (путем анализа кода IL и просмотра, какие другие API-интерфейсы он вызывает, чтобы убедиться, что он безопасен или нет)?

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

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

@davidfowl @terrajobst Будет ли это возможным дополнением к NuGet? Чтобы упростить и ускорить обнаружение совместимых с .NET Core библиотек .NET Framework?

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

Вряд ли это аргумент за или против поддержки .NET Framework или нет. Люди, которые застряли на устаревших зависимостях и не могут перейти на .NET Core (с пакетом совместимости или с библиотеками .NET Framework), не смогут сделать ни то, ни другое после него. Как это что-нибудь изменит?

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

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

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

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

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

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

Да, но какие зависимости? Для определения того, какие API-интерфейсы используют эти внешние зависимости, потребуются конкретные примеры. Этот API может быть добавлен в .NET Core 3.0 или будущую версию .NET Core.

Это позволяет использовать эту библиотеку .NET Framework в проектах .NET Core. Единственная проблема заключается в том, что библиотеки .NET Framework используют API, недоступные в .NET Standard или .NET Core. Но чтобы исправить эту обратную связь, необходимо идентифицировать библиотеки.

@pjmlp

@davidfowl

Другие также могут выбрать другие альтернативные стеки.

Это справедливо, но у альтернативных стеков такая же политика поддержки. Java перешла на аналогичную модель LTS (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

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

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

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

@ TsengSR

Несмотря на критические изменения, внесенные в Java 9, 100% всех соответствующих сред Java работают с Java 9, 10 и 11, что определенно не относится к .NET Framework, UWP и Core.

Представьте себе, что даже есть две официальные кроссплатформенные среды графического интерфейса, а у нас все еще нет официальной дорожной карты для Core!

@pjmlp

@ TsengSR

Несмотря на критические изменения, внесенные в Java 9, 100% всех соответствующих сред Java работают с Java 9, 10 и 11, что определенно не относится к .NET Framework, UWP и Core.

Представьте себе, что даже есть две официальные кроссплатформенные среды графического интерфейса, а у нас все еще нет официальной дорожной карты для Core!

Извините, это полная чушь.

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

Если вы пропустили драму и дерьмо, когда Java 9 собирался выпустить, вот ответ на это:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Чтобы помочь всей экосистеме перейти на модульную платформу Java на
более расслабленным темпом Я предлагаю разрешить незаконный светоотражающий доступ
из кода по пути к классу по умолчанию в JDK 9 и запретить его вбудущий выпуск.

В остальном, Java EE 9 устарел. JAX-WS устарел и должен быть удален в Java EE 11. Это можно примерно рассматривать как эквивалент WCF. Любое применимое, использующее его, не может быть перенесено на более новую версию, а также без замены на что-то другое, что является процессом миграции. Не более и менее отличается от перехода с ASP.NET Core на .NET Framework на ASP.NET Core на .NET Core (или с ASP.NET на ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Повышенная целостность платформы. До Java 9 в платформе можно было использовать множество классов, которые не предназначались для использования классами приложения. Благодаря сильной инкапсуляции эти внутренние API-интерфейсы действительно инкапсулированы и скрыты от приложений, использующих платформу. Это может сделать миграцию устаревшего кода на модульную Java 9 проблематичной, если ваш код зависит от внутренних API.

Любое приложение, которое использовало эти внутренние API-интерфейсы (включая все в пространстве имен sun.* которое использовалось некоторыми из старых библиотек - или использовалось, когда собиралась выпускать Java 9) или использует стороннюю библиотеку, которая зависит от в этом API или другой библиотеке может быть внесено это критическое изменение. Проблема в том, что, как и в .NET Framework и .NET Core, вы не видите только из библиотеки, какие API вызываются или нет.

@TsengSR

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

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

В остальном, Java EE 9 устарел. JAX-WS устарел и должен быть удален в Java EE 11. Это можно примерно рассматривать как эквивалент WCF.

Весь J2EE объявлен устаревшим и удален из Java 11, которая уже вышла. Но J2EE определяет только интерфейсы, а не реализацию. Чтобы продолжить использование J2EE, что я и делаю, вам просто нужно переключить зависимости. В любом случае все реализации были отдельными, и они отлично работают в Java 11.

Любое приложение, которое использовало эти внутренние API-интерфейсы (включая пространство имен all in sun. *, Которое использовалось некоторыми из старых библиотек - или использовалось, когда собиралась выпускать Java 9), или использует стороннюю библиотеку, которая зависит от этих API-интерфейсов. или другая библиотека может быть подвержена этому критическому изменению.

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

Некоторые API устарели, но мы говорим об определенных API, а не обо всей экосистеме JRE или Java. Работа, необходимая для перехода от этих API к более новым, официальным и документированным API, как правило, минимальна.

И Java всегда была более склонна нарушить обратную совместимость, чем .NET. Например, в Java теперь незаконно объявлять тип с именем var потому что он зарезервирован для локального вывода. В Java запрещено называть переменную _ потому что это зарезервировано для использования в качестве символа отбрасывания / подстановки. C # принял прямо противоположное решение в обоих случаях во имя сохранения обратной совместимости.

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

@TsengSR

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

На этом LTS тикают часы, которым некуда будет перейти, что является ключевым моментом, который игнорируется при сравнении Java LTS. Используя Java и .NET Framework, вы всегда были уверены, что сможете обновить существующие системы с минимальными усилиями, учитывая их сильную ориентацию на обратную совместимость. Поскольку пути обновления больше не существует, существующие системы вынуждены переходить на новую среду выполнения или продолжать работу на неподдерживаемой платформе. По разным причинам будут системы, в которых будет невозможно перейти на .NET Core, оставив свое будущее (с этим решением) на сохранение выполнения своих критически важных бизнес-функций на неподдерживаемой платформе.

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

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

Большинство первых (исправлений безопасности) будут исправлены через Центр обновления Windows (поскольку вы нацелены на .NET Framework). Таким образом, остались только исправления безопасности и критических ошибок, которые есть в самом ASP.NET Core.

Организации не хотят строить свое предприятие на частично поддерживаемой платформе в надежде, что любые будущие ошибки или проблемы с безопасностью будут происходить только в тех библиотеках, для которых предназначена поддержка. Было бы очень важно, если бы ASP.Core / FX охватывал тот же уровень поддержки, что и остальная часть .NET Framework, где будут устранены любые будущие уязвимости безопасности.

В настоящее время только MS сможет исправлять и выпускать обновленные пакеты ASP.Core NuGet, при этом дерево взаимосвязанных зависимостей, являющееся OSS, не поможет здесь, если только PR 2.1, которые они получают (post LTS), не будут рассмотрены, приняты и выпущенный.

В конце концов, после того, как все детали были обсуждены, главный вопрос, который все еще имеет значение:

Можем ли мы продолжить работу наших существующих систем на ASP.Core / FX?

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

Если ASP.NET Core будет только .NET Core, как мы должны относиться ко всему .NET Standard?

Если сама Microsoft не делает на это ставки по (несомненно уважительным) причинам, почему мы должны?

Будут ли первоклассные, новейшие библиотеки только для .NET Core и «более простые», менее продвинутые библиотеки .NET Standard?

Кажется, это убивает стремление к улучшению любых платформ, отличных от .NET Core.

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

Привет,
Я вижу ценность в продвижении вперед, и мне это нравится, но я вижу 3 основных проблемы в этом решении:
1) netstandard будет гражданином второго сорта, если никто внутри microsoft не создаст с ним что-то сложное, если вы, ребята, не пробуете, как вы можете попросить другого разработчика сделать это? Сегодня авторам библиотек приходится очень много работать, поддержка не улучшится, если внутренние пользователи не будут использовать стандарт.
2) есть смысл запускать ядро ​​aspnet в других средах выполнения.
3) в программном обеспечении, работающем в старых средах выполнения (с зависимостями, которые никогда не будут затронуты), есть ценность, которую не следует легко отбрасывать.

Затем идет общение: я думаю, всем просто понравится одна среда выполнения .net, которая работает везде, но это утопия в обозримом будущем, и netstandard был создан как суррогат. С моей точки зрения, каждый проект, нацеленный не на netstandard, а на платформу, - это шаг, который не идет в направлении этого видения.
Понятно, что .net framework находится в режиме обслуживания, .netcore займет свое место (оставив некоторое мертвое тело), ​​а моно будет работать на устройствах, история и CoreRT не надеются на продвижение.

С netcore 3.0 вы делаете две вещи одновременно: поддерживаете рабочие нагрузки настольных компьютеров и «говорите людям, чтобы они немедленно переходили, чтобы оставаться актуальными». Я думаю, что это потребует от разработчиков прыжка веры, и это слишком оптимистично, потому что всем известно, что многие проекты не будут перенесены из-за отсутствия некоторых зависимостей, которые, вероятно, будут добавлены в будущих выпусках 3.1 / 3.2 через 1-2 года ( очень близко к 3 LTS года 2.1). В то же время разработчики, которые хотят быть актуальными, заблокированы для использования битов 3.0 из-за зависимостей, которые они не контролируют.

Можно ли будет отложить это решение после того, как люди протестируют его и увидят реальные последствия?
Возможно ли, чтобы ядро ​​aspnet было скомпилировано как для netstandard, так и для netcoreapp, как вы предписываете авторам библиотек? Это нормально, если на платформе .NET работает снижение производительности 😄

Roslyn теперь работает на .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

Это определенно считается трудным!

@davidfowl

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

Например, Identity Server уже перешел на ASP.Net Core, и в недавнем сообщении о будущем SignalR не удивительно сказано, что ASP.Net Core SignalR будет в центре внимания будущих усилий при разработке, при этом ASP.Net SignalR находится в режиме обслуживания, который в то время было заявлено, что он будет поддерживать .Net Framework и .Net Core, и я ожидаю, что мы продолжим видеть эту тенденцию.

Я знаю, что поддержка LTS для ASP.NET Core уже установлена ​​на 3 года, но для локального развертывания необходим более длительный жизненный цикл, поскольку мы должны предоставлять поддержку по этим направлениям (4 года) нашим клиентам.
В течение этого периода мы должны иметь возможность выпускать исправления, которые включают исправления безопасности, без каких-либо серьезных изменений в приложении. Это сделано для того, чтобы соответствовать процессам управления изменениями наших клиентов, которые потребуют от них обширного пользовательского приемочного тестирования для более серьезных изменений, и чтобы нам не приходилось вносить серьезные изменения, такие как переход на более новую версию для выпусков, которые находятся в режиме обслуживания. .

Есть ли вероятность изменения политики LTS? что-то вроде стратегии Ubuntu по выпуску LTS каждые 2 года с 5-летней поддержкой - хотя я бы попросил 6, чтобы позволить текущему выпуску иметь 3+ лет поддержки, пока идет работа по переходу на новую версию.

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

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

Просто чтобы показать, какие последствия вызывает это решение - а как же Blazor? Перестанет ли он основываться на netstandard? Стоит ли нам этого ожидать?

Кто-нибудь может это прояснить?

Итак, рекомендуется ли для таких библиотек, как Newtonsoft.Json (которые могут извлечь выгоду из высокой производительности), перейти на .NET Core, а не на .NET Standard? Я не вижу особой разницы между такого рода библиотекой и ASP.NET Core. Мы встраиваем службы REST в более крупные приложения - некоторые из них можно легко перенести на .NET Core, а некоторые нет.

Насколько я понимаю, для библиотек рекомендуется использовать как .NET Core 3, так и .NET Standard 2.x, если вы хотите получить преимущества новых API-интерфейсов, но не хотите терять аудиторию.

Насколько я понимаю, для библиотек рекомендуется использовать как .NET Core 3, так и .NET Standard 2.x, если вы хотите получить преимущества новых API-интерфейсов, но не хотите терять аудиторию.

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

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

Однако я вижу большую проблему в том, что не работает на .NET Standard X . Честно говоря, мне не нужно ядро ​​asp.net для работы на xamarin или единстве, но приятно иметь возможность сказать, что это возможно - это просто еще один набор библиотек, который работает на платформе .NET. Прекращая работу, мы получаем более тесную интеграцию между .NET Core и ASP.NET Core, и я боюсь, что с .NET Core 4.5 мы осуждаем Microsoft.AspNetCore и @davidfowl, начиная с DNX 2.0.

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

Мы также можем посмотреть на это так, как вы, вероятно, собираетесь:

• .NET Core предназначен для консоли / веб / стороннего рабочего стола (стандартный + веб-API)
• Unity для игр (стандартный + API для конкретных игр)
• Xamarin предназначен для устройств / настольных компьютеров (стандартный + API для конкретных устройств / настольных компьютеров)

Но кто продвигает .NET Standard вперед? Как вы сказали ранее, ресурсы ограничены, поэтому я боюсь, что без реальной необходимости вставлять что-то (что в моем предложении попадет на основную команду .net core / asp.net, требуя изменений для выпуска LTS). NET Standard быстро устареет.

Для тех, кто не обращает внимания, кажется, что .NET Standard 2.1 только что отказался от поддержки .NET Framework.

Поскольку многие дополнения API в .NET Standard 2.1 требуют изменений во время выполнения, чтобы быть значимыми, .NET Framework 4.8 останется на .NET Standard 2.0, а не реализует .NET Standard 2.1. .NET Core 3.0, а также предстоящие версии Xamarin, Mono и Unity будут обновлены для реализации .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Как бы мне ни было больно видеть, что .Net Framework получает Silverlight-ed, в отношении ASP.NET Core для меня важно то, что он должен быть нацелен на .NET Standard .

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

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

Точно так же, как Span и т. Д. _Is_ доступен в .Net Framework через пакет nuget, я считаю разумным, что если ASP.NET Core нуждается / хочет зависеть от чего-то, чего еще нет в стандарте .Net, эта зависимость должна быть включена через пакет nuget.

Наконец, я надеюсь (вопреки всем свидетельствам об обратном), что будет .Net Framework 5.0, которая будет нацелена на .Net Standard 3.0+ и будет устанавливаться параллельно с 4.x.

Наконец, я надеюсь (вопреки всем свидетельствам об обратном), что будет .Net Framework 5.0, которая будет нацелена на .Net Standard 3.0+ и будет устанавливаться параллельно с 4.x.

Да, точно. Это то, о чем я говорю уже много лет: архитектура CLR 2.0 хорошо нам служила в течение долгого времени, но она начинает давить на зуб, и пришло время для фундаментального обновления того же типа, что и Generics. Это может быть несколько болезненным , чтобы внести необходимые изменения, но они необходимы; обновление с новыми, более мощными функциями необходимо точно так же, как и Generics, и откладывание его только усугубит эту боль, а не уменьшит ее, когда это наконец произойдет.

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

@terrajobst сказал, что этого не произойдет: см. https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
Да, кроме двух вещей.

1. Core не является обновлением Framework; это параллельная концепция. Есть так много действительно фундаментальных вещей, которые он не может сделать, многие из которых, например, домены приложений, как нам говорят, вряд ли когда-либо произойдут. Ради всего святого, у нас до сих пор нет даже рабочего Reflection.Emit ! Учитывая, насколько часто это встречается в компиляторах и инструментах генерации кода, можно подумать, что это было бы буквально одним из первых приоритетов, и все же вот мы, 4 года спустя, и это не работает! Из-за этого очень сложно серьезно отнестись к понятию «Core как замена / обновление .Net Framework».
2. Core не меняет радикально среду выполнения в стиле CLR 2.0. На странице «Какие языковые предложения выиграют от изменений CLR?» у нас есть отличный список отсутствующих функций, которые люди считают важными, которые CLR не может поддерживать (или, по крайней мере, не может поддерживать без массивных, уродливых клуджей для обхода ограничений CLR), как правило, из-за отсутствующих функций в системе типов. Сколько предложений по этой теме вообще серьезно воспринимается основной командой? И сколько остальных из них было сразу уволено, потому что люди, управляющие проектом, не хотят обновлять среду выполнения? Мы получаем DIM и ... что-нибудь еще? Вообще ничего?

Так что нет, .NET Core - это не обновленная .NET Framework, которая делает столь необходимые обновления CLR, потому что это не обновленная .NET Framework, и команда проекта делает все возможное, чтобы избежать обновления CLR, где это возможно. Это буквально полная противоположность этому.

Ради всего святого, у нас до сих пор нет даже работающего Reflection.Emit! Учитывая, насколько часто это встречается в компиляторах и инструментах генерации кода, можно подумать, что это было бы буквально одним из первых приоритетов, и все же вот мы, 4 года спустя, и это не работает! Из-за этого очень сложно серьезно отнестись к понятию «Core как замена / обновление .Net Framework».

Было бы здорово понять, что не работает. ASP.NET Core и EF используют излучение отражения в нескольких местах, поэтому я не знаю о больших пробелах. Вы можете здесь уточнить?

Он был там по крайней мере с 2.0 .. iirc даже 1.0 имел DefineDynamicAssembly, хотя, возможно, не весь набор инструментов emit.

Мне также трудно серьезно отнестись к мысли, что они избегают обновления CLR. Вы видели огромный объем проделанной работы? https://github.com/dotnet/coreclr/commit/master
Для C # 8 предусмотрены языковые функции, которые также будут работать только в .NET Core из-за изменений среды CLR. Многие из этих возражений кажутся устаревшей информацией (что вполне справедливо, поскольку планы Microsoft временами быстро менялись ...)

@davidfowl

Было бы здорово понять, что не работает. ASP.NET Core и EF используют излучение отражения в нескольких местах, поэтому я не знаю о больших пробелах. Вы можете здесь уточнить?

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

Это было исправлено? Я был бы рад услышать, что в нем ...

@gulbanna

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

Я сказал, что они избегают радикального обновления CLR таким же образом, как обновление 2.0 (дженерики).

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

@masonwheeler

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

Глядя на https://github.com/dotnet/corefx/issues/4491 (где вы уже комментировали в прошлом), я думаю, что ситуация остается прежней. Хотя я думаю, что отсутствие одной конкретной функции (даже если она важная) сильно отличается от того, что «у нас до сих пор нет даже работающего Reflection.Emit ».

что делает Core бесполезным для разработчиков компилятора, таких как я

Чем полезен Reflection.Emit для составителя компилятора? Я думал, что он был ограничен производством сборок для текущей структуры, поэтому его вообще нельзя было использовать для создания, например, сборок .Net Standard, что, я думаю, было бы значительным ограничением для любого компилятора.

Я сказал, что они избегают радикального обновления CLR таким же образом, как обновление 2.0 (дженерики).

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

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

@svick

Хотя я думаю, что отсутствие одной конкретной функции (даже если она важная) сильно отличается от того, что «у нас до сих пор даже нет работающего Reflection.Emit».

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

Чем полезен Reflection.Emit для составителя компилятора?

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

по-прежнему не ожидал бы новых инструкций IL, когда встроенные функции JIT часто могут работать так же хорошо

Конечно, но как насчет случаев, когда они этого не делают?

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

Вы видели предложение по реализации фигур в существующей системе типов? В этом нет ничего разумного; это большой, уродливый кладж от начала до конца. (Ничего не имею против людей, которые его придумали; это вроде как должно быть, учитывая ограничения, с которыми он работает.) И удачи в реализации метаклассов вообще без поддержки уровня CLR!

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

Может кто-нибудь из команды .net пояснить, пожалуйста, каковы их рекомендации для локального развертывания? Это просто "использовать asp.net обычный"? Я говорю конкретно о комментариях @ Edward84

Влияет ли это на библиотеки поддержки Microsoft.Extensions.* ? А именно Microsoft.Extensions.Logging и Microsoft.Extensions.Configuration .

У нас есть большая база кода с общим API-интерфейсом. Некоторые из них - это WinForms, некоторые - классический ASP.NET, некоторые - WCF и т. Д. И новейшие приложения - это .NET Core (не сейчас, но в конечном итоге, когда мы перенесем наши основные библиотеки на стандарт .NET)

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

Поэтому мне интересно, безопасно ли их использовать в .NET Standard API, на который ссылаются как .NET Core, так и .NET Framework (4.7.2+), или они также могут начать использовать только функции .NET Core?

@mvestergaard Как упоминалось в самом объявлении :

Пакеты Microsoft.Extensions (такие как ведение журнала, внедрение зависимостей и конфигурация) будут по-прежнему поддерживать .NET Standard.

И в комментарии @benaadams в этой ветке :

Не все библиотеки переходят только на .NET Core (например, Microsoft.Extensions.* остаются как .NET Standard)

@mvestergaard, как уже упоминалось, мы изучаем нашу политику LTS, чтобы определить, полезны ли такие вещи, как расширенная поддержка, более длительные периоды, период «режима обслуживания» и т. д., и как они будут выглядеть. Мы также работаем над тем, чтобы увидеть, сможем ли мы сделать расписание новых поездов LTS более предсказуемым (модель, которую мы видим и которой мы действительно восхищаемся из других стеков, у которых есть модель LTS).

Самая большая проблема, с которой я сталкиваюсь, заключается в том, что я не могу использовать зрелые пакеты, которые можно использовать только при нацеливании на .NET Framework, или те, которые были просто недоступны за пределами .NET Framework, например, те, которые нуждались в System.Drawing и GDI +.

Похоже, что последний сценарий будет поддерживаться в .NET Core 3.0, однако, AFAICT, мы все равно упустим использование стабильных, зрелых библиотек, которые можно использовать только в .NET Framework.

Примером этого является Entity Framework . Нам придется переключиться на незрелое ядро ​​EF Core, которое, похоже, очень далеко от обработки всех сложных сценариев, которые может выполнять полный EF, и

Примером этого является Entity Framework. Нам придется переключиться на незрелое ядро ​​EF Core, которое, похоже, очень далеко от обработки всех сложных сценариев, которые мог бы выполнить полный EF ...

EF6 будет поддерживаться в .NET Core 3.0, как объяснил @DamianEdwards на этой неделе в сообществе ASP.NET Standup - 6 ноября 2018 г. - Возможности ASP.NET Core 3.0 в 19:06

@benaadams , это отличные новости! довольно непонятно для такого большого дела! :) хорошая работа. Нашел еще одно упоминание об этом здесь .

@SaebAmini : Вы можете использовать System. Опираясь на .NET Core. См. System.Drawing.Common и сообщение в блоге Скотта Хансельмана: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

А до этого CoreCompat.System.Drawing существовал как порт System.Drawing Mono.

Есть ли какая-либо функция, которая отсутствует для вашего варианта использования при работе в .NET Core?

@TsengSR, мой конкретный сценарий, который заставил нас ориентироваться на .NET Framework, был:

1. Необходимость использования пакета Microsoft Solver Foundation, доступного только в .NET Framework.
2. Пакет для создания изображения штрих-кода, который использовал System.Drawing.
3. Необходимость использования EF6.

Это было около года назад.

@SaebAmini : как уже упоминалось ранее, поддержка EF6 входит в .NET Core 3.0, System.Drawing уже существует (а до этого пакет CoreCompat существовал и мог работать в вашем случае) и для пакета Microsoft Solver Foundation, после запущенный анализатор API переносимости:

См. Как использовать анализатор переносимости

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (загрузите его и откройте HTML-код, другого места для размещения не нашел).

Он показывает 97,93% совместимость с .NET Core 2.0 + Platform Extensions (который был выпущен около года назад) и перечисляет несовместимые API, которые в основном связаны с устаревшими System.Web и System.ServiceModel / System.Data.Linq .

Раньше я не использовал этот пакет, и я не уверен, зачем решателю нужен доступ к System.Web и HttpContext или System.ServiceModel , но если вы не используете мне не нужны какие-либо тезисы (и вы знаете, что ваш вариант использования не вызывает эти API-интерфейсы), шансы довольно высоки, что вы можете использовать его в .NET Core 2.0 / 2.1 + Platform Extensions или в .NET Core 3.0, даже если он специально не нацелен на целевой псевдоним netstandard или netcoreapp20 .

Так что технически велики шансы, что вы могли перенести свое приложение на .NET Core 2.0 + Platform Extensions год назад, если бы EF Core 2.0 мог удовлетворить потребности ваших приложений (конечно, это требует некоторой работы по миграции и обновлений для работы с EF Core 2.0).

Да, требуется немного больше работы, чтобы проанализировать рассматриваемые библиотеки или функцию для замены фреймворка (EF6 -> EF Core 2.0 / 2.1), но это далеко не невозможно. Я не думаю, что люди могут или должны ожидать портировать весь свой код 1: 1 в ASP.NET Core без каких-либо изменений (за пределами самого ASP.NET Core).

Просто хотелось бы, чтобы было более очевидно, чтобы отображалась совместимость API, например, с помощью «значка» (совместим с .NET Core 3.0) и / или подробного отчета о совместимости API где-нибудь на странице nuget, чтобы сделать это более очевидным, чем необходимость загрузки пакета а затем прогнать через анализатор пакетов.

Я думаю, что это объявление было бы лучше воспринято, если бы оно подчеркивало, насколько более совместимым стало .NET Core. Есть два фактора, способствующих перемещению ASP.NET Core с .NET Framework:
1) Снижение потребности в .NET Framework, доступность устаревших приложений, улучшение взаимодействия и т. Д.
2) Увеличение преимуществ .NET Core, возможностей и производительности, а также снижение нагрузки на обслуживание.

Фактор 2 вырисовывается в умах людей, которым действительно нужно создавать ASP.NET! Тем не менее, с точки зрения пользователя, это мало что дает. У людей есть вещь , которая работает , и их наивысшим приоритетом является то , что он должен продолжать работать. Хорошая новость в том, что в большинстве случаев так и будет.

Я согласен с @gulbanana. .NET Core теперь намного более совместим с .NET Framework. Фактически, я смог запустить довольно большие приложения .NET Framework, просто переименовав .exe в .dll и добавив некоторые недостающие .DLL в путь проверки.

Прогресс в инструментах командной строки dotnet впечатляет. Особенно добавление глобальных инструментов .NET Core. Они упрощают разработку.

Компиляция AOT с crossgen великолепна. Я могу продолжать и продолжать.

tl / dr .NET Core сегодня производит серьезное впечатление.

Чего не хватает:

• Текущая стратегия коммуникации с клиентами отсутствует. Клиенты сильно разочаровываются, когда слышат, что их любимая платформа .NET фрагментирована Microsoft. Здесь вам следует быть более ясным. Например, было бы гораздо лучше напрямую рекламировать людям уникальную, высокосовместимую, быструю и перспективную реализацию .NET. Как .NET Core, будущее .NET, которое решит большинство ваших проблем, взлетная производительность, креативность, открытие новых рыночных ниш и т. Д.
• Еще больше стратегий совместимости из коробки
• Графический пользовательский интерфейс. Я имею в виду, что инструменты командной строки dotnet великолепны, но в настоящее время нам приходится использовать дополнительные текстовые редакторы и консоль для работы почти над каждым проектом в формате .NET SDK. В этом отношении пользовательский интерфейс Visual Studio отсутствует. Это создает большие препятствия для многих людей, которые имеют привычку просто указывать и щелкать. Это тоже нужно улучшить
• LTS поддержка

@TsengSR Спасибо за подробный ответ, приятель, отличная информация! в то время использование пакета штрих-кода не сработало, поскольку проект просто не компилировался с жалобами на разные цели. Может, стоит попробовать еще раз. (если вы не имели в виду перекомпилировать его и наследовать его)

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

Здесь много смешанных вопросов. Мои личные 2 цента - это то, что оставить .NET Framework не так уж и важно. Однако вызывает беспокойство полное отсутствие какой-либо очевидной поддержки усилий по стандартизации (.NET Standard). Конечно, вы, вероятно , не захотите запускать ASP.NET Core, скажем, на Unity сегодня, но это не о сегодняшнем дне. Примерно через год или два, когда может появиться еще одна среда выполнения .NET, я хотел бы сказать: «Да, как только SuperNetRuntime будет поддерживать .NET Standard 2.2, мы сможем запускать на нем ASP.NET Core 3». ...

Есть ли шанс хотя бы «собрать» все изменения, которые требовались в .NET Core 3 для ASP.NET Core 3, и направить их рабочей группе .NET Standard в качестве предложений?

Привет, будут ли пакеты, опубликованные для .NetStandard 2.0 или .NetCore 2.0, продолжать работать с .NetCore 3.0. Например: Oracle.ManagedDataAccess.Core target .NetCore 2.0

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

.NetFramework имеет историю совместимости, даже если вы можете использовать .NetFramework 2.0 в последних версиях, поэтому что-то необходимо поддерживать для .NetCore также, по крайней мере, от 2.0 до 3.0 и т. Д.

благодаря

Привет, будут ли пакеты, опубликованные для .NetStandard 2.0 или .NetCore 2.0, продолжать работать с .NetCore 3.0. Например: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Да, .NET Core 3.0 поддерживает обратную совместимость, поэтому можно использовать библиотеки .NetStandard 1.0 -> .NetStandard 2.1 и .NetCore 1.0 -> .NetCore 2.2

@benaadams, тогда это хорошо. Также будет ли .net framework dll работать, если они не используют отсутствующий api?

благодаря

Также будет ли .net framework dll работать, если они не используют отсутствующий api?

Да, хотя безопаснее использовать стандартную библиотеку .NET, поскольку вы знаете, что она будет работать на .NET Core (и на Mono, Xamarin, Unity, UWP)

Кроме того, использование пакета обеспечения совместимости с

Привет народ,
Чтобы предоставить клиентам разумную отправную точку на пути к миграции приложений на ASP.NET Core на .NET Core, мы собираемся расширить поддержку и обслуживание для ASP.NET Core 2.1.x на .NET Framework, чтобы соответствовать текущей поддержке. политика для других платформ ASP.NET на основе пакетов , например MVC 5.x, Web API 2.x, SignalR 2.x. Это фактически означает, что пакеты, связанные с ASP.NET Core 2.1.x (окончательный подробный список подлежит уточнению), будут поддерживаться бессрочно, по истечении трехлетнего периода LTS для .NET Core 2.1 в целом.

Отличные новости. Спасибо, что прислушиваетесь к своим клиентам.

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

@DamianEdwards Это отличные новости! Просто интересно, исправлено ли это до версии 2.1.x или она будет обновлена ​​до версии 2.2.x, если она станет выпуском LTS? В 2.2 было много усилий, но она еще даже не выпущена. И поскольку он продолжает поддерживать совместимость со стандартом netstandard и отлично работает на всей структуре, было бы напрасной тратой полностью пропустить это для расширенной поддержки.

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

@DamianEdwards Да, я понимаю, спасибо за ответ. Я просто спросил, потому что последний комментарий по этому поводу заключался в том, что это еще не решено , поэтому я просто хотел знать, будет ли эта расширенная поддержка продолжена, если 2.2 станет LTS.

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

Новые функции не входят в LTS, поскольку они направлены на стабильность.

Однако это не совсем соответствует предыдущим решениям LTS.

@poke

Однако это не совсем соответствует предыдущим решениям LTS.

Это меня смутило. В каком смысле? Вы имеете в виду тот факт, что 1.1 был добавлен в состав 1.x LTS? Если так, то это была аномалия нашей первой серии релизов, которая больше не повторится. Двигаясь вперед, наша цель состоит в том, чтобы более согласованно с тем, какие выпуски становятся LTS по сравнению с текущими (т.е. где я могу получить стабильность по сравнению с функциями).

@DamianEdwards Я в основном имел в виду тот факт, что каждый выпуск до сих пор был большим выпуском функций, и каждое решение LTS обычно принималось ретроспективно (по крайней мере, публично).

@poke ОК. Итак, на данный момент у нас было 4 релиза (1.0, 1.1, 2.0, 2.1), и скоро выйдет пятый (2.2). Из них только 1.0 и 2.0 изначально предназначались для LTS, но из-за ряда факторов (в основном связанных с тем, что мы действительно новички в проектировании таким образом 😉) мы закончили тем, что 1.0, 1.1 и 2.1 были поездами LTS. 2.0 и 2.2 являются (были, будут) текущими выпусками. На этом этапе 3.0 почти наверняка также будет Текущим (в результате чего 2.2 войдет в Текущий «льготный» период в 3 месяца) до того, как 3.1 станет LTS-поездом 3.x. Мы надеемся, что после этого узор и частота вращения педалей будут более последовательными (нам бы это понравилось), но пока наш хрустальный шар нас подвел.

@DamianEdwards Спасибо за понимание! 😄 (Между прочим. Я не пытался спорить об этом, мне просто было любопытно;))

Более серьезной проблемой для нас являются новые API-интерфейсы REST, размещаемые в процессе устаревшими приложениями, которые вряд ли в ближайшее время перейдут с .NET Framework. По крайней мере, мы знаем, что сейчас не продвинуться дальше поддерживающих библиотек .NET Standard 2 и ASP.NET Core 2.1! Хорошо, что срок LTS продлится

Привет всем, быстрый вопрос: как насчет тех из нас, кто использует собственные пакеты в форме C ++ / CLI? Будет ли это поддерживаться в .Net Core в ближайшее время, или мы останемся сиротами, если не проведем масштабную переработку для использования P / Invoke?

@lokitoth - это хороший вопрос для пользователей https://github.com/dotnet/core, потому что это более общий вопрос, чем просто ASP.NET Core.

@lokitoth да, это будет поддерживаться, см. https://github.com/dotnet/coreclr/issues/18013

oO Как я это пропустил?

Ладно, тогда у меня с этим проблем нет.

@ danroth27 Не могли бы вы рассказать нам о влиянии этой проблемы на Client-Side-Blazor?

@Slkebe Я не ожидаю никакого воздействия. Клиентские приложения Blazor не зависят от среды выполнения или платформы, которую вы решили запускать на сервере.

@ danroth27 Насколько я понимаю, Blazor на стороне клиента может работать в моно, потому что зависимые пакеты Microsoft.AspNetCore.* нацелены на netstandard.
Я что-то упускаю? Blazor должен продолжать нацеливаться на Microsoft.AspNetCore.* 2.1.X?

@Slkebe Клиентские библиотеки Blazor зависят только от компонентов, которые будут продолжать работать с .NET Standard (например, Microsoft.Extensions. * И других). Серверные части Blazor, зависящие от ASP.NET Core, будут нацелены на .NET Core, как описано в этой проблеме.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Какое теперь решение? Таргетинг на стандарт .net 2.1?

@ John0King Нового решения нет.

Это бананы! БАНАНЫ

я с пониманием отношусь к вашей точке зрения.

Приносим извинения, если это уже поднималось, но как насчет случаев использования, когда я просто хочу использовать Kestrel + некоторое промежуточное программное обеспечение как часть приложения, отличного от ASP.NET? Придется ли мне тянуть все дерево 3.0 (что не идеально, поскольку мой вариант использования включает определение пользовательского SDK для потребителей), или этот вариант использования не поддерживается в 3.x?

В настоящее время я разрабатываю приложение ASP.NET Core, работающее на .NET Framework, из-за включенных библиотек. Я использую ASP.NET Core из-за его возможностей множественной авторизации. Я чувствую себя обманутым и запертым.

Я использую ASP.NET Core из-за его возможностей множественной авторизации.

@FlorianGrimm Что конкретно? Microsoft.Owin предоставил аналогичные функции аутентификации для ASP.NET 4.

Это гибридное приложение с одним исходным кодом (.exe), работающим локально и в лазурном режиме, в настоящее время использующее Windows auth, aad, базовую проверку подлинности и анонимность.

@FlorianGrimm Какие зависимости библиотеки мешают вам использовать .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom и Microsoft.SharePointOnline.CSOM.

Я надеюсь, что команда SharePoint закончит
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
и я нахожу другие варианты, кроме ilspy.

В любом случае мне нравится ASP.NET Core, и я надеюсь, что другие команды Microsoft предоставят больше сборок .NET Core.

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

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