Aspnetcore: Новые пакеты ASP.NET Core 2.0 больше нельзя использовать в .NET Desktop.

Это было бы крайне странным и плохим изменением. Я написал много кода ядра asp.net только для netfx и не хочу, чтобы эти инвестиции были потрачены впустую. В более общем плане клиентам .NET в обозримом будущем потребуется обеспечить взаимодействие между кодом ASP.NET Core и Desktop — представьте себе веб-приложения, которые используют Active Directory или автоматизацию Office COM, или которые делают миниатюры с помощью некоторого System.Drawing на основе библиотеки или поделиться кодом с приложением WPF. Тривиально думать о множестве подобных сценариев, и я надеюсь, что мы просто неправильно поняли, что происходит.

В настоящее время мы работаем с AspNetCore 1.1.1, то есть с «текущей» веткой поддержки. Если мы не можем перейти на 2.0 из-за зависимости от Net4XX, означает ли это, что мы перестанем поддерживаться, когда выйдет версия 2.0+3 месяца?

Мы используем комбинацию WPF и ASP.NET Core и в обоих случаях ориентируемся на полную платформу.
Я так понимаю 2.0 в обозримом будущем не будет?

Но полный фреймворк 4.6.1 будет поддерживать netstandard 2? я что-то пропустил? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

разве это не то, что текущий инструментарий не обновляется?

было бы совершенно нормально, и ожидается, что ядро ​​​​asp.net будет работать на сетевом стандарте 2. Тревожной вещью является перспектива перехода на сетевое ядро ​​app2.0, что означает невозможность использования устаревшего кода внутри asp.net. основные веб-сайты

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

Было бы неплохо услышать аргументы команд по этому поводу.

о, так вы думаете, что проекты netcoreapp2.0 смогут просто ссылаться на библиотеки netfx благодаря унификации типов? Это объяснило бы многое. мой вопрос, если это так, заключается в том, сколько кода на самом деле будет работать при запуске в Windows, но в основной CLR.

Вот это да. Это полностью заблокировало бы нас и, по сути, гарантировало бы, что мы никогда не сможем обновлять эти пакеты в обозримом будущем. Нам даже может понадобиться перенести наш проект MvcCore обратно на Mvc, потому что в настоящее время мы не можем обойти таргетинг на net462+.

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

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

Возможно , @DamianEdwards или @davidfowl могут прокомментировать планы здесь? У меня также возникли проблемы с поиском каких-либо дополнительных рассуждений.

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

• Вы сказали, что клиентам .NET потребуется взаимодействие. Полностью согласен.
  
  
  
  • Мы можем совместно использовать библиотеки netstandard между ASP.NET Core 2.0 и ВЕЗДЕ.
  
  
  • Мы даже можем ссылаться на многие сборки net461+ из ASP.NET Core 2.0 благодаря переадресации типов и netstandard20.
  
  
• Вы сказали, что веб-приложениям может потребоваться использовать:
  
  
  
  • AD. В общем, это пробел, ЕСЛИ вы хотите вызывать LDAP напрямую. Вы, безусловно, можете авторизоваться с Windows Auth СЕЙЧАС. Мы планируем создать специальное пространство имен DirectoryServices для Core 2.0 в летнее время.
  
  
  • Рисунок – В общем, это пробел. Мы планируем сделать это для Core 2.0 примерно летом. До этого эти параметры сетевого стандарта также существуют для параметров ImageSharp, ImageResizer, Mono и т. д.
  
  
  • COM-автоматизация — это никогда не было возможно в Core 2.0, но вы, безусловно, можете использовать PInvoke, если хотите навредить себе. Вы также можете привязать WebAPI к процессу net461+, если действительно хотите навредить себе.
  
  
  • Совместное использование кода с приложениями WFP — ДА. Вполне возможно с netstandard2.0.
  
  
• Это странное изменение.
  
  
  
  • Такое ощущение, но…
  
  

Подумайте об этом таким образом. WPF не является netstandard2.0, он знает, что находится в сети 461+, и это нормально. Он оптимизирован, но может ссылаться на сетевые стандартные библиотеки. ASP.NET Core 2.0 оптимизирован для Core 2.0, но может ссылаться на общие библиотеки. Xamarin такой же.

.NET Core идет рука об руку и быстро развивается. Это НАМНОГО быстрее, чем .NET (Full) Framework, что хорошо. Создавая ASP.NET Core 2.0 поверх .NET Core 2.0 (который, как вы помните, является СУПЕРНАБОРОМ .NET Standard), это означает, что вещи можно создавать быстрее, чем NetFx или даже Netstandard.

NetCore > Net Standard > NetFx, когда речь идет о скорости разработки и инновациях.

Дело в том, что если вы делаете новую работу, netstandard20. Если у вас есть старые библиотеки net461+, на БОЛЬШИНСТВО из них можно ссылаться в ASP.NET Core 2.0.

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

Остальные большие пробелы, отсутствующие в .NET Core 2, — это System.DirectoryServices и System.Drawing. Мы работаем над созданием пакета совместимости для Windows, который этим летом позволит использовать обе версии .NET Core в Windows.

Что нам нужно от вас всех, так это четкий список/понимание того, ПОЧЕМУ вы думаете, что вам нужен ASP.NET Core 2.0 для работы на net461+.

Я думал, что .NET Standard 2.0 полностью посвящен совместимости и взаимодействию, которые устраняют разрыв между .NET Core и .NET fx, которого все ждут — это, кажется, убивает это.

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

Предполагается ли, что клиенты не смогут создавать приложения ASP.NET Core 2.0, работающие в CLR для настольных ПК, чтобы они могли ссылаться на свои существующие зависимости .NET 4.x?

@shanselman Спасибо за ответ - там много хороших примеров.

Дополнение о библиотеках:
Будут ли все библиотеки абстракций оставаться кросс-компилированными? Например, если я использую HttpRequest , поддержка сборок 1.x и 2.x на той версии ASP.NET Core, которую вы используете (которая теперь точно сопоставляется, по крайней мере, с TFM) будет чем-то Я бы предпочел избежать... поэтому я надеюсь , что абстракции останутся на netstandard . Это общий план?

Мы уже поддерживаем несколько вариантов для вещей, которые зависят от ASP.NET/MVC, потому что System.Web HttpRequest полностью отличается, так что это совершенно другая библиотека (например, MiniProfiler против MiniProfiler.AspNetCore ). Я просто хочу убедиться, что мы учитываем количество вариантов, которые мы загружаем для поддержки любых авторов библиотек, если их зависимости удаляются netstandard ... и, надеюсь, просто избегаем этой головной боли вместе.

Я очень рад, что это не так важно, как кажется, спасибо за подробное разъяснение.

У меня есть два вопроса/проблемы:

• Похоже, что использование библиотек .NET Framework из ASP.NET Core должно быть минимальным. Замечательно! А как насчет наоборот? Вероятно, существуют библиотеки и приложения .NET Framework или netstandard, которые встраивают части или компоненты из Mvc и других поддерживающих библиотек ASP.NET Core (я знаю, потому что у меня есть пара). Они сломаются, верно? Есть ли какие-нибудь советы, как обойти этот сценарий? Если библиотеки netstandard больше не могут использовать библиотеки ASP.NET Core, это кажется большой проблемой для встроенных сценариев ASP.NET Core.

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

Мы даже можем ссылаться на многие сборки net461+ из ASP.NET Core 2.0 благодаря переадресации типов и netstandard20.

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

Многие из «старых» API, повторно представленных в .NET Core 2.0, представляют собой заглушки, которые никогда (функционально) не будут работать. Не говоря уже о том, что по-прежнему существует множество отсутствующих API и даже целые области, намеренно исключенные из .NET Core (IdentityModel, сервер WCF, удаленное взаимодействие, полная поддержка AppDomain и т. д.)

Попытка убедить людей в том, что они могут «безопасно» перенести свои приложения ASP.NET Core 1.0 с .NET Desktop на ASP.NET Core 2.0 с .NET Core, ИМХО — ложь.

.NET Core идет рука об руку и быстро развивается. Это НАМНОГО быстрее, чем .NET (Full) Framework, что хорошо. Создавая ASP.NET Core 2.0 поверх .NET Core 2.0 (который, как вы помните, является СУПЕРНАБОРОМ .NET Standard), это означает, что вещи можно создавать быстрее, чем NetFx или даже Netstandard.

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

@daveaglick

• Правильно в том, что нет неявной возможности ссылаться на netcoreapp2.0 из net461 или даже из netstandard2.0 . Мост идет в одну сторону. Вы всегда можете обойти это, указав TFM для отката пакета, но это, очевидно, выходной люк, а не поддерживаемый сценарий (хотя этого будет достаточно, чтобы разблокировать многих людей). Для нас требуется нетривиальный объем работы по поддержке подсистем ASP.NET Core за пределами более крупного стека (что подразумевает таргетинг на netstandard ).
• Потенциальная путаница идет в обоих направлениях. Например, мы получили много отзывов о том, что тот факт, что «ASP.NET Core» может работать на .NET Framework (который не является .NET Core), сбивает с толку. Это изменение фактически делает ASP.NET Core частью стека .NET Core, что означает, что если вы используете ASP.NET Core, вы используете .NET Core.

@shanselman Кстати, вы не сказали, почему кросс-компиляция невозможна. Компоненты ASP.NET Core, которые могут извлечь выгоду из API-интерфейсов только на netcoreapp2.0 , могут иметь как net46 / netstandard1.x / netstandard2.0 , так и netcoreapp2.0 TFM и сделать новые крутые/быстрые вещи только для .NET Core.

@NickCraver в настоящее время план не включает оставление пакетов *.Abstractions, нацеленных на netstandard . Разделение просто не такое чистое, как по всем направлениям. Однако для тех, кто пытается выполнить миграцию, подобную тому, что вы предлагаете, использование отката целевого пакета все равно должно привести вас к этому (но я могу вас неправильно понять).

Также вы указываете, что чистое разделение TFM является правильным и является преимуществом этого плана, поскольку теперь один пакет может одновременно ориентироваться на ASP.NET Core 1.x и 2.0+, используя TFM в качестве опорной точки.

Я играю с идеей «смешанных приложений». Например, приложение WPF, предоставляющее веб-API, или сервер, предлагающий как REST API, так и конечные точки WCF (это может быть для совместимости с более ранними клиентами). Это изменение делает эти сценарии невозможными и делает ASP.NET Core пригодным только для новых приложений, а не «просто библиотекой».

@PinpointTownes , как заявил @shanselman , нас очень интересуют конкретные требования и блокировщики, которые есть у клиентов в отношении необходимости продолжать напрямую ориентироваться на .NET Framework. Наша работа с клиентами в этой лодке до сих пор показала, что System.DirectoryServices и System.Drawing , а также блокировщики №1 и 2, и у нас есть план по решению этой проблемы. Кроме того, мы смотрим на отзывы и оцениваем их.

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

@DamianEdwards Спасибо за дальнейшее разъяснение. Библиотеки netstandard -> ASP.NET Core для меня очень важны. Я встраиваю Kestrel (который также, похоже, переезжает в netcoreapp) в несколько библиотек netstandard. Я также встраиваю Razor в несколько мест, и я знаю, что вы работаете над новой, более модульной версией, но если она нацелена только на netcoreapp, это будет больно. Есть также множество библиотек, которые являются «частью» ASP.NET Core, но имеют множество полезных функций вне его.

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

Сам @daveaglick Razor (движок) будет по-прежнему нацелен на netstandard . Опять же, поддержка определенных подсистем большого сложного графа (например, ASP.NET Core 2.0) на разных платформах связана с затратами. Для таких вещей, как встраивание, есть другие варианты (встраивание исходного кода, копирование и т. д.), но, конечно, они имеют свои собственные компромиссы.

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

Я разделяю опасения @daveaglick здесь: желание ASP.NET Core использовать новейшие API-интерфейсы вполне понятно, но для всего остального нижестоящего требования того же становится немного сложнее. У вас нет выбора после версии 1.0, стабильной или обновленной, вы находитесь на самом быстром поезде, доступном с netcoreapp2.0 , и это единственный выбор. Если все биты (даже базовые абстракции) не могут быть использованы без того, чтобы пользователи потребляли netcoreapp2.0 , это означает, что фактически нет netstandard2.0 для всей этой линейки библиотек... и все это зависит от них.

Я перемещаю основной стек приложений, но я не обязательно согласен с перемещением абстракций, в частности. Один из основных моментов абстракций заключался в том, чтобы избежать подобной тесной связи, по крайней мере, с моей точки зрения потребителя. Мне было бы очень любопытно увидеть некоторые примеры, когда netstandard2.0 не имеет необходимых для них API, а netcoreapp2.0 имеет — есть ли какие-нибудь примеры? Это в основном связано с новыми типами в параметрах метода? Я не сомневаюсь, что есть достаточные рассуждения, мне просто очень любопытно - просмотр примеров поможет показать стоимость обслуживания, о которой у нас не так много ежедневного понимания.

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

@PinpointTownes , как заявил @shanselman , нас очень интересуют конкретные требования и блокировщики, которые есть у клиентов в отношении необходимости продолжать напрямую ориентироваться на .NET Framework.

В качестве консультанта я помог нескольким клиентам перенести свои приложения на ASP.NET Core, и мне часто приходилось ориентироваться на .NET Desktop, чтобы иметь возможность использовать сторонние библиотеки (с закрытым исходным кодом) в зависимости от IdentityModel / WCF или AppDomain. служба поддержки.

Отсутствие этих вещей в ASP.NET Core 2.0 было бы серьезным препятствием для них.

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

В .NET Core RSA.Create() возвращает экземпляр RSACng в Windows, но в .NET Desktop возвращается экземпляр RSACryptoServiceProvider . Тем не менее, многие библиотеки, включая саму BLC, пытаются преобразовать RSA в RSACryptoServiceProvider , что всегда будет терпеть неудачу в .NET Core, поскольку RSACng нельзя преобразовать в RSACryptoServiceProvider .

@NickCraver , какие именно абстракции? Проблема с перемещением только абстракций заключается в том, что в дальнейшем вам понадобится все, что основано на этих абстракциях (если только вы буквально не говорите, что вам нужен только Microsoft.AspNetCore.Http.Abstractions и ничего больше)

@davidfowl Да, только абстракции: например, HTTP, хостинг, HTML и ведение журнала. Похоже, Microsoft.Extensions.* охвачены более ранними комментариями, а это большинство из них. Это те, с которыми я взаимодействую сегодня.

Для конкретного примера: промежуточное ПО MiniProfiler не отвечает ни на что, кроме абстракций ( ссылка )

Если вы используете MVC и тому подобное, то вы в любом случае на netcoreapp2.0 , и это то, что есть (и IMO, это просто отлично). Но в настоящее время у меня есть свобода логически разделять API, где они совместно используются, и делать это легко, потому что они являются абстракциями. Я очень люблю нынешний раскол, пожалуйста, не закрывайте его без необходимости.

Хе. Как консультант, я определенно слышал "Что? ASP.NET Core работает на настольной .NET Framework!?" вопрос довольно много раз. Тот факт, что «ASP.NET Core» буквально имеет в названии «.NET Core», действительно прискорбен.

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

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

Это включает в себя мой текущий клиент, который имеет безумно большую устаревшую библиотеку/фреймворк, ориентированную на .NET Framework, используемую несколькими проектами ASP.NET Core, которые в настоящее время разрабатываются параллельно. К тому времени, когда эти системы будут запущены в производство, практически не будет времени либо а) перенести все на .NET Core, либо б) перевести все на полную платформу ASP.NET до того, как ASP.NET Core 1.x перестанет поддерживаться.

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

@khellang , как указывалось ранее, они смогут продолжать ссылаться на библиотеки/фреймворки, ориентированные на .NET Framework, и это будет прекрасно работать, если предположить, что API, которые они вызывают, являются частью закрытия netstandard2.0 . Знаете ли вы, полагаются ли они на вещи за пределами этого пространства? Это то, о чем мы действительно хотели бы получить отзывы, чтобы мы могли оценить приоритет переноса этих API (например, System.DirectoryServices и System.Drawing ).

Таким образом, размещение веб-API (скажем, коммуникационного уровня) или даже будущих основных сокетов asp.net станет невозможным для текущей службы Windows или настольного приложения WPF? (с поддерживаемыми версиями).

Я полагаю, что скоро появится список вещей, которые раньше стоили netstandard1.x , а теперь стоят netcoreapp2.0

Я просмотрел репозитории, и мне кажется, что специфичные для MVC вещи стоят netcoreapp2.0 , но HttpAbstractions, Logging, Configuration и т. д. по-прежнему netstandard Или есть еще изменения?

@NickCraver Я вижу, вы используете Extensions, но все еще используете System.Web. Есть ли у вас планы сменить Microsoft.AspNetCore.Http.HttpContext на System.Web.HttpContext ? Вы представляете, сколько API вам нужно?

Если вы используете MVC и тому подобное, то вы в любом случае используете netcoreapp2.0, и это то, что есть (и IMO, это просто отлично). Но в настоящее время у меня есть свобода логически разделять API, где они совместно используются, и делать это легко, потому что они являются абстракциями. Я очень люблю нынешний раскол, пожалуйста, не закрывайте его без необходимости.

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

Службы Windows @dasMulli будут работать, как только мы перенесем API (есть также библиотеки с открытым исходным кодом, которые поддерживают службы Windows в .NET Core).

Настольное приложение WPF? (с поддерживаемыми версиями).

да. Это больше не будет по умолчанию. Мы больше не будем поддерживать его из коробки с .NET Core 2.0.

@davidfowl Я не уверен, что вы смотрели на правильные фрагменты:

но все еще используют System.Web

... не в одних и тех же библиотеках из-за этого разделения. Чтобы добиться минимальных накладных расходов, а не множества зависимостей для потребителей, существует MiniProfiler для ASP.NET MVC < 6 (System.Web) и MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (множество NuGet ).

Я думаю , вы говорите об остатках System.Web , которые были на MiniProfiler.Shared — я ждал, чтобы очистить их, пока вчера вечером проблема NuGet не была устранена в сборках фреймворка. Я просто удалил его , чтобы прояснить ситуацию.

@DamianEdwards Я не на 100% уверен в закрытии netstandard2.0 , но я был бы рад (с их разрешения) запустить анализатор переносимости и поделиться результатами. Анализатор переносимости все еще актуален и актуален?

ASP.Net Core быстро становится новым Python 3*; только хуже. Это кажется мне движением в неправильном направлении. Это просто означает, что множество сценариев заставят разработчиков поддерживать (и писать новый) код на «старых платформах» в течение многих лет вместо того, чтобы переезжать. «Быстрая разработка» не кажется очень хорошим аргументом, если все, что это означает, это то, что вы попадаете в худшее/неподходящее место «Быстрее».

*Мне нравится Python 3, но он вышел уже почти десять лет назад, а сообщество Python все еще раздроблено.

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

@shanselman Я вижу ваши доводы и лично я даже согласен, но _много_ людей так не увидят.

Основная проблема заключается не в вызове сборок net46 из ядра, в большинстве случаев с этим справляются прокладки совместимости. Проблема заключается в существующем коде net46 и коде asp.net core 1. *, работающем на 46. Как кто-то упомянул, весь смысл netstandard заключался в том, чтобы позволить коду, включая asp.net, работать везде, это будет похоже на шаг от этого и, возможно, даже провал этого видения для некоторых людей.

Я не думаю, что проблема в том, что люди _не хотят_ переходить на net core. Проблема в том, что организации, менеджеры, технические директора и им подобные должны быть убеждены, что затраты/выгоды того стоят. Мало того, что перенос занимает достаточно времени, чтобы съесть поставки, он также создает риски регрессии и т. д.

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

Если вы хотите навредить себе

Это точно. Разработчики и руководство Net46 не увидят этого, они увидят, что _вы_, Microsoft, хотите навредить им, чтобы не отставать от последней версии. «Ну, тогда не двигайтесь», можно сказать, но с поддержкой asp.net core 1.x, какой бы короткой она ни была, они вроде как должны, по крайней мере, с точки зрения менеджеров, которые должны нести ответственность, если ошибка приводит к простою или потере информации. (даже если фреймворк не несет ответственности)

Многие разработчики, которые действительно настаивали на asp.net core 1.1, также почувствуют себя обманутыми из-за того, что теперь они не смогут перейти на 2.0 без ядра. Это может быть или не быть оправданным, но я просто говорю вам, многие люди будут чувствовать себя так, они будут теми, кто будет отвечать перед своими более консервативными коллегами.

Имеет ли это значение? «Умрет» ли asp.net core2/dotnet core2 из-за этого? Нет, но это замедлит внедрение и разрушит экосистему, и это действительно печально. Я хочу, чтобы люди могли использовать все эти замечательные вещи, появившиеся в версии 2.0, и сокращение кросс-компиляции до сетевого стандарта повлияет на это. Конечно, у большинства людей, которые зависают в этих репозиториях, не будет проблем, проблема в Джо и Джейн, а тем более в их менеджере.

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

Чтобы подвести итоги, я уверен, что это решение было принято нелегко, но если вам нужно это сделать, я думаю, вы должны быть очень _действительно_ осторожными с обменом сообщениями.. Вы должны показать, что переход на ядро ​​​​asp.net, особенно с 1. x на net46 _супер_ простой и супер отточенный. История со ссылками на другие библиотеки netstandard из net46 как в качестве ссылок на проекты, так и в других случаях должна быть надежной. Я думаю, вам нужно показать/обращаться к этому явно, чтобы люди не сходили с ума.

@khellan пейджинг @terrajobst для вопроса об анализаторе переносимости.

@кхелланг

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

@NickCraver Конечно, вы можете написать часть промежуточного программного обеспечения, ориентированного на netstandard, что хорошего это даст вам как автору библиотеки, если ASP.NET Core поддерживает netcoreapp2.0.

@ aL3891 отличное резюме! Одна большая проблема, которая у нас есть в будущем, заключается в том, как мы используем преимущества новых API для вещей, которые также находятся в netstandard. .NET Core получит новые API, необходимые для реализации новых функций (на ум приходит поддержка SSLStream ALPN для поддержки HTTP2 в Kestrel). Таким образом, вы можете возразить, что мы остаемся на netstandard и постоянно используем самую последнюю версию (которую .NET Framework еще не поддерживает), но тогда мы будем в одной лодке.

Одна большая проблема, которая у нас есть в будущем, заключается в том, как мы используем преимущества новых API для вещей, которые также находятся в netstandard. .NET Core получит новые API, необходимые для реализации новых функций (на ум приходит поддержка SSLStream ALPN для поддержки HTTP2 в Kestrel).

Согласно https://github.com/dotnet/corefx/issues/4721 , поддержка ALPN для SslStream не будет готова для .NET Core 2.0. Если предположить, что через несколько месяцев это в конечном итоге будет реализовано, значит ли это, что можно будет использовать его при нацеливании на netcoreapp2.0 TFM? В этом случае, что произойдет, если я решу выпустить библиотеку на основе netcoreapp2.0 , которая использует новые API, которые не были частью первоначальной формы netcoreapp2.0 , если мои пользователи используют более старую среду выполнения .NET Core? ? Будет ли это крах? Или netcoreapp2.x будет выровнен с netstandard1.x , чей контракт нельзя изменить без увеличения версии TFM?

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

Если абстракции на самом деле не являются абстракциями и так тесно связаны с самим ASP.NET Core, почему бы нам просто не удалить эти пакеты? Это честный вопрос, так как это сделало бы жизнь проще и понятнее, если бы это была общая цель отношений. Я пытаюсь понять смысл наличия абстракций в виде отдельных пакетов, если они эффективно привязаны к простой реализации/использованию. Я бы сказал, что никто за пределами Microsoft не хочет или не имеет ресурсов для выделения конкурирующего веб-сервера netcoreapp2.x (рад, что его там поправили!).

Можете ли вы пояснить, в чем смысл абстракций в мире netcoreapp2.x ? Или если есть планы просто отказаться от них в 2.0?

Согласно dotnet/corefx#4721, поддержка ALPN для SslStream не будет готова для .NET Core 2.0. Если предположить, что через несколько месяцев это будет реализовано, значит ли это, что его можно будет использовать при нацеливании на netcoreapp2.0 TFM? В этом случае, что произойдет, если я решу выпустить библиотеку на основе netcoreapp2.0, которая использует новые API, которые не были частью исходной формы netcoreapp2.0, если мои пользователи используют более старую среду выполнения .NET Core? Будет ли это крах? Или netcoreapp2.x будет приведен в соответствие с netstandard1.x, чей контракт нельзя изменить без увеличения версии TFM?

Версия ASP.NET x будет просто соответствовать версии .NET Core x. TFM будет обновляться для соответствия каждому выпуску .NET Core. Это единственный продукт, который, наконец, можно рассматривать как таковой. Это одно из основных упрощений, которые мы делаем, как упоминает @DamianEdwards выше. Мы не будем ломать людей, создающих библиотеки, добавляя новые API в ядро ​​без изменения TFM.

@НикКравер

для других реализаций любой части стека и тестирования.

Какие еще реализации? Существуют ли другие части стека, реализующие ASP.NET Core.

Если абстракции на самом деле не являются абстракциями и так тесно связаны с самим ASP.NET Core, почему бы нам просто не удалить эти пакеты? Это честный вопрос, так как это сделало бы жизнь проще и понятнее, если бы это была общая цель отношений. Я пытаюсь понять смысл наличия абстракций в виде отдельных пакетов, если они эффективно привязаны к простой реализации/использованию. Я бы сказал, что никто за пределами Microsoft не хочет или не имеет ресурсов для выделения конкурирующего веб-сервера netcoreapp2.x (рад, что меня там поправили!).

Можете ли вы пояснить, в чем смысл абстракций в мире netcoreapp2.x? Или если есть планы просто отказаться от них в 2.0?

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

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

Мы не будем ломать людей, создающих библиотеки, добавляя новые API в ядро ​​без изменения TFM.

Вы, ребята, сказали, что хотите выбрать netcoreapp2.0 — только потому, что он работает быстрее — по сравнению с .NET Desktop и, соответственно, .NET Standard — но какой смысл ориентироваться на netcoreapp2.0 вместо netstandard2.0 , если вы не можете воспользоваться новыми API-интерфейсами .NET Core без изменения TFM? (например, netcoreapp2.1 )

Вы, ребята, сказали, что хотите выбрать netcoreapp2.0-only, поскольку он работает быстрее — по сравнению с .NET Desktop и, соответственно, .NET Standard — но какой смысл ориентироваться на netcoreapp2.0 вместо netstandard2.0, если вы можете Не можете воспользоваться новыми API-интерфейсами .NET Core без изменения TFM? (например, netcoreapp2.1)

Извините, я оговорился, я имею в виду netcoreapp2.x , а не netcoreapp2.0 .

Ладно, теперь я совсем запутался.

Извините, я оговорился, я имею в виду netcoreapp2.x, а не netcoreapp2.0.

Я не уверен, что понимаю. Вы имеете в виду, что будет эквивалентность между пакетами ASP.NET Core 2.1 и TFM netcoreapp2.1 ?

Вы имеете в виду, что между пакетами ASP.NET Core 2.1 и TFM netcoreapp2.1 будет эквивалентность?

Ага. Думайте о 2 как об одном в том же самом. См. https://github.com/aspnet/Home/issues/2022#issuecomment-299544884 .

Так что же мешает вам принять аналогичный шаблон, но с netstandard ? Это был бы лучший подход, ИМХО: новые API-интерфейсы могут быть приняты с помощью новых TFM, и люди, которым необходимо поддерживать .NET Desktop, могут по-прежнему запускать свои приложения ASP.NET Core на полной платформе.

ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2 .

@PinpointTownes, потому что .NET Framework для настольных ПК не может поставляться достаточно быстро, в этом суть большинства проблем с версиями в Core. Это трудная задача в огромной цепи.

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

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

Кросс-компиляция — это накладные расходы, которые должны быть сбалансированы с потребностями клиента и продукта.

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

Что нам нужно от вас всех, так это четкий список/понимание того, ПОЧЕМУ вы думаете, что вам нужен ASP.NET Core 2.0 для работы на net461+. Будьте конкретны, чтобы мы могли закрыть эти пробелы и позволить всем добиться успеха.

На данный момент нам нужна полнофункциональная версия клиентских библиотек WCF, так как версии netstandard / netcore (https://github.com/dotnet/wcf) не близки к завершению.

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

В самом ближайшем будущем наступит время, когда мы буквально не сможем полифилить такие функции, как поддержка ALPN для SSLStream. Кроме того, мы даже не начали разминать ноги и добавлять API в .NET Core, пока что мы увязли в переносе вещей обратно в .NET Standard и .NET Core 2.0 (вся цель .NET Standard 2.0) . Мы собираемся добавлять новые API и, наконец, использовать их в ASP.NET Core в первый день.

На данный момент нам нужна fullframework версия клиентских библиотек WCF — так как версии netstandard/netcore (https://github.com/dotnet/wcf) не близки к завершению.

@ctolkien Это проблема, и именно поэтому мы в первую очередь портировали клиент WCF. Вы знаете, что вам мешает? Это хороший шанс помочь нам расставить приоритеты.

@davidfowl https://github.com/dotnet/wcf/issues/8

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

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

Как это проблема? AFAICT, никто здесь никогда не говорил, что версии .NET Desktop и .NET Core ASP.NET Core должны поддерживать один и тот же точный набор функций. Если функция недоступна в .NET Desktop из-за отсутствия API (например, HTTP 2/0), почему бы не сделать ее только для .NET Core и не выдать PlatformNotSupportedException , сообщая разработчику, что функция, которую он ищет, недоступно?
Это было бы намного лучше, чем делать все пакеты ASP.NET Core только для .NET Core, даже несмотря на то, что большинство из них вряд ли будут использовать новые API-интерфейсы BCL.

@davidfowl Я думаю, один из основных страхов заключается в том, что вещи не исправляются, скажем, в netcoreapp2.3 , они исправляются в netcoreapp2.4 . Если ASP.NET Core ориентирован на самый быстрый поезд, как долго с каждой младшей версией получать любовь? Если нам приходится постоянно обновляться, то каждый потребитель должен постоянно обновляться.

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

Если абстракции не нуждаются в быстром обновлении (примеры?), было бы предпочтительнее их отключить. Таким образом, вы не перетаскиваете всю экосистему при каждом обновлении. Думаю, меня больше беспокоит не то, что они будут на netcoreapp , а то, что они будут постоянно обновляться и все будет тесно связано.

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

@PinpointTownes :

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

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

Это сбой во время выполнения и очень нежелательное поведение.

Это именно то, что произойдет с подходом «перенесите свои сборки .NET Desktop на .NET Core», если ваши сборки попытаются использовать неподдерживаемый API, за исключением того, что вы получите MissingMemberException вместо PlatformNotSupportedException .

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

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

@PinpointTownes Я тоже так думал, но реальность такова, что появляются новые платформы, и это не так просто. После многократных обсуждений этого я сильно изменил свое мнение о том, как делать компат здесь. Движение в направлении netcoreapp позволяет отправлять исправления в дополнительных версиях. Если вы пойдете другим путем, вам придется подождать, пока .NET Desktop отправит исправления, что... удачи. Это очень медленное средство для разрешения.

AFAICT, никто здесь никогда не говорил, что версии .NET Desktop и .NET Core ASP.NET Core должны поддерживать один и тот же точный набор функций. Если функция недоступна на .NET Desktop из-за отсутствия API (например, HTTP 2/0), почему бы не сделать ее только для .NET Core?

Первая половина этого - это то, что netstandard . Дифференциация на netcoreapp — это именно то, что они здесь делают. Без преднамеренных исключений. Это правильный контракт на этом маршруте.

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

[@PinpointTownes] Если функция недоступна на .NET Desktop из-за отсутствия API (например, HTTP 2/0), почему бы не сделать ее только для .NET Core и не выдать PlatformNotSupportedException , сообщая разработчику, что эта функция он ищет не доступен?

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

Движение в направлении netcoreapp позволяет отправлять исправления в младших версиях.

Чем это отличается от подхода 1.0? @davidfowl сказал, что для новых API потребуются новые TFM, а это означает, что вам придется отказаться от LTS, чтобы получать исправления, основанные на новых API .NET Core. Не совсем идеальная ситуация.

Отличие от netcoreapp — это именно то, чем они здесь занимаются.

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

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

Конечно. Но вам также необходимо сбалансировать это с тем фактом, что устаревшие библиотеки, разработанные для .NET Desktop и использующие функции, недоступные в .NET Core, должны нормально работать в ASP.NET Core 2.0, как и в 1.0.

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

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

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

Тогда обратная связь, обзоры и рекомендации могут быть сделаны вне повседневного шума репозиториев кода? Или общий обзор API / репозиторий спецификаций (вроде csharplang против roslyn)

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

[@benaadams] Может быть, стоит создать репозиторий с перенаправлением портов в dotnet, где люди могут делать запросы API для определенных элементов, которые они считают отсутствующими в .NET Core, из .NET Framework?

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

[@benaadams] Или репозиторий общих обзоров/спецификаций API

Не уверен, что оно того стоит. Обзоры API уже несколько неуклюжи; извлечение их в другое репо, кажется, усиливает это. Я бы предпочел, чтобы мы продолжали оптимизировать CoreFx, чтобы добавление новых API было таким же простым, как, скажем, в ASP.NET.

как указывалось ранее, они смогут продолжать ссылаться на библиотеки/фреймворки, ориентированные на .NET Framework, и это будет прекрасно работать, если предположить, что API, которые они вызывают, являются частью закрытия netstandard2.0.

@DamianEdwards А как насчет API, не включенных в закрытие netstandard2.0? Большинство сторонних библиотек имеют закрытый исходный код. Как я могу сказать, что каждый пограничный случай находится в закрытии netstandard2.0?
Как намекнул @PinpointTownes , это похоже на игру в русскую рулетку.

Инструмент @MJomaa поможет здесь, но, очевидно, единственный способ узнать наверняка — это запустить его. На самом деле это ничем не отличается от библиотеки .NET Standard, работающей на платформе, поддерживаемой .NET Standard. Существующие API не заменяют необходимость тестирования этих библиотек. Это не означает, что реализации netstandard не стремятся быть совместимыми, но они являются граничными, например https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt .

Это API, которые существуют в NS 2.0, но отсутствуют в .NET Framework 4.6.1.

Я очень нервничал по поводу этого изменения, но после прочтения ветки в теории кажется, что все в порядке. У нас есть 5 приложений ASP.NET Core, 4 из них — на полной платформе, но в основном мы занимались обороной и шли по пути наименьшего сопротивления.

Я думаю, что какие-то инструменты, встроенные в VS, такие как .NET Core Portability Analyzer, могли бы помочь разработчикам, которые не в курсе последних событий в Twitter/GitHub и не знают, что это расширение вообще существует. На ум приходит всплывающее окно «предложить расширение», но я не уверен, какое действие предпримет человек, чтобы вызвать это. Возможно, вы пытаетесь добавить библиотеку net46x в приложение ASP.NET Core 2+?

Вещи, которые Microsoft не может контролировать, такие как сторонняя поддержка с Telerik, Syncfusion и т. Д., Также могут быть потенциальными блокаторами в зависимости от того, что они делают.

Сообщения в этой ветке GitHub должны быть как можно скорее опубликованы в блоге с часто задаваемыми вопросами или чем-то в этом роде. Мне кажется, что я был в курсе всего, и я все еще не был на 100% уверен, означает ли это, что мы можем ссылаться на библиотеки net46x или нет. Я явно был не единственным, кого это смутило.

Чтобы повторить то, что говорили другие. Я разговаривал как минимум с 10 разработчиками, которые не знали, что ASP.NET Core может работать на полной платформе. У меня был тот же опыт, что и у @aL3891, хотя разработчики были действительно счастливы, что могли запускать ASP.NET Core на полной платформе, и их внутренние библиотеки просто работали. Опять же, сообщения о том, что .NET Core 2.0 имеет подавляющее большинство вариантов использования, будут очень и очень важными. Часть о наличии хотя бы решения только для Windows, например System.DirectoryServices, также будет важна. Многие NET-разработчики, с которыми я разговаривал, пожимают плечами, когда слышат, что .NET Core является кроссплатформенным, и больше заботятся о том, чтобы их существующий код работал, чем о x-plat/perf.

Ребят, это какой-то бред :(
Мы построили поверх ASP.NET Core из-за возможности использовать его с netfx, и мы создали вещи, которые были рассчитаны на 5-10 лет, а не на 1 год поддержки максимум. Вот что означает имя ASP.NET в бизнесе, и именно поэтому крупные, медленно развивающиеся организации выбирают его, а не разнообразие месячных фреймворков. Позвольте мне перейти к конкретным вариантам использования.

Я работаю в инструментальной группе, которая создает линейку бизнес-библиотек и приложений для внутреннего использования в компании и для продажи «корпоративным» клиентам. В нашем случае это в основном государственные организации, но я уверен, что вы услышите то же самое и от частного сектора. У нас есть внутренние фреймворки, которые кодируют бизнес-шаблоны в общие абстракции — например, IDatabaseConnection, IEntityProvider, IWizardFlow, ICodeGenerator — и создают интерфейсы RAD поверх этих подключаемых бэкендов.

В нашем стеке ASP.NET Core — это «плагин» — это HTTP-адрес назначения, используемый в качестве абстракции хранилища данных, для хостинга служб и т. д. Это также «интерфейс» — очевидно, множество бизнес-приложений — это веб-сайты, и это отличная новая структура для веб-приложений. Таким образом, у нас есть требования к двунаправленному взаимодействию — код AN-C, который ссылается на случайные другие компоненты, и случайный другой код, который ссылается на AN-C.

Мы полные поклонники Core CLR и переносимости, и мы перенесли множество наших компонентов на целевой или многоцелевой сетевой стандарт. На данный момент у нас есть одно приложение, размещенное на Linux, и мы надеемся, что в будущем их станет больше. Тем не менее, нет никакого способа, чтобы все было перенесено в ближайшее время! У нас есть еще живой, активно развивающийся код, который опирается на

• Проверка подлинности NTLM (включая расширенные сценарии использования токенов и имен участников-служб)
• System.Drawing, как указано выше (здесь есть интересная загвоздка: нам нужны старые форматы изображений, такие как TIFF, которые новые библиотеки OSS не поддерживают)
• Подключение к WCF/SOAP apis - их еще тонны и тонны
• API шифрования Windows (включая RSACng, ECDSA и CSP для токенов PKI)
• Графический интерфейс WPF — наши клиенты не перейдут на Windows 10 в ближайшее время, и даже когда они это сделают, им не понадобятся приложения для Магазина.
• Взаимодействие с Microsoft Office (в частности, доступ и Excel) для импорта и экспорта данных
• Расширяемость Visual Studio
• Сторонние плагины, такие как поставщик Oracle ADO.NET.

Некоторые из этих технологий никогда не будут поддерживаться Core CLR. Но это настоящие технологии, лежащие в основе разработки новых приложений — нам нужна версия .NET, которая имеет доступ к этим вещам. Прямо сейчас наша позиция управляема: мы изолируем «устаревшие» (на самом деле: специфичные для платформы) зависимости в их собственные компоненты, специфичные для net461. Затем определенные бизнес-приложения зависят от netfx, если им нужны эти функции, а не иначе. Я предвижу будущее, в котором это редкость для новых приложений... но трудно представить, что когда-либо будет 0%.

Вы проделали всю эту работу над csproj и SDK, потому что взаимодействие важно. ASP.NET Core — это пряник, причина , по которой нужно взаимодействие. Не думаю, что есть смысл его убирать. И нет, «вы можете загружать свои ссылки в одном направлении, но они, скорее всего, не будут работать во время выполнения» — это не интероперабельность.

@gulbanana Можете ли вы описать части системы, использующие ASP.NET Core, почему они должны быть в том же процессе, что и .NET Framework. Я ценю список (подключения Visual Studio, взаимодействие с офисом и т. д.), но внедряете ли вы ASP.NET Core во все эти места сегодня (у меня нет хорошей картины из приведенного выше описания)?

Кроме того, что вы использовали до появления ASP.NET Core? Или это просто новое начинание, которое никогда не использовало ASP.NET, но сделало 5-10-летнюю ставку на ASP.NET Core на .NET Framework? Катану смотрел?

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

NTLM/AD

Для целей единого входа у нас есть приложения, которые полагаются на то, что браузер передает учетные данные для входа в Windows в IIS, который передает их на веб-сайт ASP.NET Core. Затем частью процесса аутентификации является поиск информации о том, находится ли пользователь в определенной группе AD. Мне бы очень хотелось узнать больше о «пакете поддержки Windows» и о том, предназначен ли он для таких вещей.

System.Drawing

Это используется в веб-приложении, которое создает миниатюры и основные изменения изображений (поворот, наложение водяных знаков). Многие из используемых изображений относятся ко временам динозавров, поэтому там есть такие вещи, как TIFF. Это данные, хранящиеся в правительственном ведомстве и относящиеся к конкретным спискам собственности и управлению земельными ресурсами. В этом случае приложение изначально было ASP.NET MVC и было обновлено/переписано с помощью MVC 2, 4, 5, а теперь и Core.

VSIX

Это случай встраивания AN-C в netfx, а не наоборот. У нас есть расширения Visual Studio для генерации кода, которые запускают «шаблоны» для различных сценариев RAD. Некоторые из этих шаблонов были созданы для веб-разработки и ссылаются на типы AN-C во время разработки (они создаются с использованием препроцессора/среды выполнения T4).

Крипто

Я думаю, что это действительно должно быть внутрипроцессно - у нас есть сценарии лицензирования, в которых код очень чувствителен к безопасности. В общих чертах, это расшифровка и проверка файлов лицензий в отношении среды, в которой выполняется код — это обычная библиотека, используемая в серверной части веб-приложений, а также в настольных приложениях. В конце концов, похоже, что .NET Core получит достаточную криптоподдержку, чтобы ее можно было портировать, но сегодня этого не произошло. Например, сегодня у нас есть один вариант — поддержка токенов PKI Fortinet/ePass2003, где их промежуточное ПО определенно не поддерживает Core (и для этого нет временных рамок).

Oracle ADO.NET

Использование Entity Framework 6 с серверной частью Oracle не обязательно должно быть внутрипроцессным, но для наших веб-сайтов было бы неудобно добавлять дополнительный уровень только для доступа к базе данных!

Взаимодействие WPF

В наши дни мы используем Microsoft.Extensions.Logging во всех наших настольных приложениях — сами абстракции ведения журнала должны быть внутрипроцессными, даже если реализации нет.

Что касается того, что мы использовали до ASP.NET Core — ASP.NET MVC! Мы могли бы вернуться, но было бы большим позором отказаться от всех преимуществ.

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

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

NTLM/AD

Это имеет смысл, и я хотел бы понять, с какими API это в конечном итоге сопоставляется. Это просто System.DirectoryServices? Над этим активно работают (вы можете увидеть это в corefx).

System.Drawing

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

VSIX

Где здесь ASP.NET Core? Он работает внутри расширения визуальной студии?

Крипто

Есть ли проблема с corefx для этого? Почему бы просто не портировать? В отличие от .NET Framework, выпуски .NET Core отделены от ОС, поэтому вполне возможно, что это может произойти раньше, чем позже, если это будет сочтено важным. (Отказ от ответственности: я недостаточно знаю о криптографии, чтобы понять последствия этой кроссплатформенной работы).

Oracle ADO.NET

При чем здесь ASP.NET Core? Вы просто говорите, что провайдер Oracle еще не перенесен на .NET Core?

В наши дни мы используем Microsoft.Extensions.Logging во всех наших настольных приложениях — сами абстракции ведения журнала должны быть внутрипроцессными, даже если реализации нет.

Microsoft.Extensions.* останется сетевым стандартом, так что вы защищены этим.

Почему нет анонса/обсуждения?
Мне нравится то, что делает основная команда aspnet/.net, но у меня те же страхи, что и у @jhurdlow.

Рад слышать о MEL. По остальным пунктам-

NTLM

Вот один класс, который используется в большинстве наших приложений. Он довольно тривиально использует API, который, надеюсь, можно было бы портировать в теории (но этого не произошло).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

Шаблоны codegen, характерные для ядра asp.net, используют систему действий/маршрутизации (IFileProvider и т. д.) для обнаружения контроллеров, представлений и т. д. и заполнения наших каркасов. Мы не размещаем веб-хост ASP.NET внутри Visual Studio, а просто анализируем приложения ASP.NET.

Крипто

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

Оракул

Да, это будет решено, если произойдет порт Oracle (при условии, что он полнофункциональный и т. д.).

Еще один вариант использования:
Одно из наших приложений импортирует устаревшие данные из приложения Access. Прямо сейчас этот процесс импорта выполняется на сервере на основном веб-сайте asp.net. Он использует COM-взаимодействие для загрузки acedao.dll из распространяемого движка accdb/jet, считывает таблицы в наши абстракции сущностей, а затем сохраняет их в более современной базе данных SQL.

Это еще один случай «может быть не в порядке, но почему это должно быть». По сути, мы использовали бы AN-C в качестве внешнего интерфейса для веб-сайта WebAPI 2 или чего-то еще, и в этом случае мы вернулись к этой зависимости от прошлого :(

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

ВТФ!!! 😨
Вы говорите, что ASP.NET Core 2 больше не будет ориентироваться на Full .NET framework 4.x !!!
Мы только начали проект 1 месяц назад с ASP.NET Core 1.1, и мы нацелились на .NET 4.6, потому что мы ссылаемся на некоторые полные библиотеки .NET. И мы собирались перейти на ASP.NET Core 2. Но то, что я слышу из этого поста... 😞
Послушай, мы выбрали ASP.NET Core из-за его преимуществ (DI, объединенный API и MVC, ... мощный), поэтому, пожалуйста, давайте в качестве изменения, чувак.

Мы только начали проект 1 месяц назад с ASP.NET Core 1.1, и мы нацелились на .NET 4.6, потому что мы ссылаемся на некоторые полные библиотеки .NET.

Что делают эти библиотеки? Вы читали первоначальный ответ @shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123? На некоторые библиотеки .NET Framework можно ссылаться в .NET Core 2.0 (при условии, что они остаются в подмножестве API).

Что делают эти библиотеки? Вы читали первоначальный ответ @shanselman № 2022 (комментарий)? На некоторые библиотеки .NET Framework можно ссылаться в .NET Core 2.0 (при условии, что они остаются в подмножестве API).

@davidfowl да, я прочитал комментарий @shanselman , мы используем некоторые библиотеки, сделанные компанией, некоторые из этих библиотек используют WCF, все эти библиотеки стабильны, они нацелены на .NET 3.5, и мы не можем их трогать.

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

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

• большинство клиентов, которые у меня есть сегодня, используют комбинацию asp.net core 1.x/full framework, потому что они боятся идти ва-банк на новые вещи.
• Судя по количеству загрузок пакетов nuget, внедрение ядра asp.net не очень хорошо. С этим шагом будет еще немного сложнее продать то, что сейчас плохо продается.
• здорово, что вы определили материал LDAP как пробел (я думаю, что за последние 10 лет я никогда не видел, чтобы кто-то использовал эти библиотеки, но, возможно, это только я). Более серьезной проблемой будут сторонние библиотеки. Это будут настоящие причины, по которым люди не перейдут на ядро ​​.net.

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

Я могу ошибаться, но я думал, что .NET Core теперь находится под управлением DNF, поэтому эти решения больше не являются чисто внутренними для MS.

Материалы LDAP/AD определенно являются причиной, по которой мне нужно оставаться на вершине net462 прямо сейчас. Хотелось бы полностью перейти, BAM -> NetCore полностью, но это недостаток.

Я также использую XML-RPC.net в одном из своих проектов. В нем используется серьезный Reflection.Emit, и я не уверен, что NetCore 2 будет поддерживать его полностью. Однако мне придется попробовать анализатор переносимости, чтобы убедиться в этом.

Я нахожу всю эту ситуацию немного обескураживающей из-за того, как быстро и легко такое важное решение, которое влияет на будущее .NET, может быть принято без какой-либо прозрачности, в последнюю минуту, еще раз. Много энергии было вложено в продажу существующей экосистемы .NET при переходе на ASP.NET Core с сообщением (насколько я понимаю), что .NET Standard 2.0 будет сосредоточен на совместимости и станет выпуском, который устраняет разрыв с .NET. v4.x, чтобы, наконец, создать надежную и стабильную платформу .NET, от которой, наконец, может зависеть экосистема. Я лично не верю, что .NET Core действительно взлетит до тех пор, пока не будет выпущен .NET Standard 2.0, поскольку я ожидал, что это будет «стабильная земля обетованная», которую мы все ждем — теперь я понятия не имею, что такое «.NET Standard». 2.0» означает, что именно он будет охватывать и какие библиотеки планируется использовать только для .NET Core.

Поскольку не было предварительного официального объявления, запроса на отзыв, опроса или обоснования, это решение «похоже» было принято без участия сообщества или анализа воздействия на существующую экосистему .NET и, вероятно, фрагментирует всю экосистему для многих. годы вперед. Отказ от поддержки .NET v4.x лишает многие предприятия плавного пути миграции, чтобы они могли перенести свои существующие кодовые базы на новую модель разработки ASP.NET. Это не подтолкнет их к более быстрому переходу на .NET Core, а фактически предотвратит даже попытки сделать это, что приведет к массивной фрагментации, которая разорвет экосистему .NET на две части. Я не вижу, чем это в конечном итоге будет отличаться от Python 2/3, которому был нанесен непоправимый ущерб фрагментацией, от которой он до сих пор не может восстановиться почти за десять лет.

Большинство существующих кодовых баз .NET — это браунфилд, разрабатываемый за кулисами «темной материи» разработчиков .NET, большинство из которых не будет знать, что это решение было принято, учитывая, что .NET Core 1.1 поддерживает .NET v4.x. а обмен сообщениями для .NET Standard 2.0 был обещанием улучшения совместимости. Я ожидаю массовой негативной реакции, как только новости и влияние этого решения наконец дойдут до людей. Многие разработчики, которые продавали внедрение .NET Core внутри своей организации, почувствуют себя преданными, учитывая, что они фактически перешли на тупиковую платформу (если они не могут полностью перейти на .NET Core по какой-либо причине). ) суровая реальность, с которой им придется столкнуться сразу после того, как они преуспеют в монументальном решении убедить заинтересованные стороны в своей организации утвердить ресурсы, необходимые для их текущей миграции.

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

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

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

Этот корабль уплыл или есть возможность оставить ASP.NET Core 2.0 как есть? то есть с большинством библиотек и абстракций, охватываемых .NET Standard 2.0, а затем в следующем выпуске ASP.NET Core 3.0 объявляется, что следующей платформой будет только .NET Core? Это позволит организациям продолжать двигаться вперед и внедрять ASP.NET Core 2.0, а остальная часть экосистемы сможет наверстать упущенное благодаря стабильным и хорошо поддерживаемым инструментам и библиотекам, в то же время имея четкое разделение между платформами .NET Core и платформами. особенности начинаются.

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

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

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

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

Моя точка зрения при создании библиотеки заключается в том, чтобы сделать ее максимально простой для использования как можно большим количеством людей в максимально возможном количестве мест. Это головная боль (поищите директивы компилятора #if в Newtonsoft.Json, и вы получите более 1300 результатов), но фраза «Это просто работает» является мощным аргументом в пользу продажи.

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

Реальный вопрос: ASP.NET Core 1.x в настоящее время поддерживает .NET Framework и .NET Core. Допустим, это была стабильная платформа, которую вы упомянули выше, которую мы исправили и поддерживали в обеих средах выполнения, но не получили дополнительных функций. Будет ли этого достаточно?

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

Этот корабль уплыл или есть возможность оставить ASP.NET Core 2.0 как есть? то есть с большинством библиотек и абстракций, охватываемых .NET Standard 2.0, а затем в следующем выпуске ASP.NET Core 3.0 объявляется, что следующей платформой будет только .NET Core? Это позволит организациям продолжать двигаться вперед и внедрять ASP.NET Core 2.0, а остальная часть экосистемы сможет наверстать упущенное благодаря стабильным и хорошо поддерживаемым инструментам и библиотекам, в то же время имея четкое разделение между платформами .NET Core и платформами. особенности начинаются.

Мы всегда открыты для обратной связи, и ASP.NET Core 2.0 еще не выпущен. Если бы ASP.NET Core 3.0 был выпуском, в котором отказалась от .NET Framework, улучшило бы это ситуацию? Если вы посмотрите на некоторые отзывы от @gulbanana и @ikourfaln , то увидите, что есть технологии, которые, скорее всего, никогда не будут перенесены и, следовательно, никогда не будут работать на .NET Core. Разве это не означает, что поддержка .NET Framework будет практически вечной? Разве у нас не было бы такого же обсуждения через год? Может быть, к тому времени экосистема или библиотеки, поддерживающие .NET Core, станут больше, и это окажет меньшее влияние? А как насчет тех корпоративных библиотек, которые никогда не будут обновляться (или исходный код которых был утерян)? Изменятся ли они через год?

Моя точка зрения при создании библиотеки заключается в том, чтобы сделать ее максимально простой для использования как можно большим количеством людей в максимально возможном количестве мест. Это головная боль (поищите директивы компилятора #if в Newtonsoft.Json, и вы получите более 1300 результатов), но фраза «Это просто работает» является мощным аргументом в пользу продажи.

Без обид @JamesNK, но JSON.NET — это парсер JSON и по большей части один пакет (я знаю, что есть еще несколько). ASP.NET Core имеет> 200 пакетов.

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

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

В соответствии с планами мы не можем перенести ни одно из наших приложений на netstandard / netcoreapp до тех пор, пока не будет доступно System.DirectoryServices ( проблема CoreFX № 2089 здесь ). Так что, хотя мы можем перенести на ASP.NET Core 1.x, мы не можем перейти на 2.0. Глядя на приложения здесь: Opserver, само переполнение стека, наши внутренние приложения ... ничего не будет готово, поскольку на данный момент 2.0 представлен. Согласно стендапу на этой неделе, такие важные вещи, как DirectoryServices, по-прежнему появятся в более позднем выпуске 2.x.

Таким образом, между версиями 1.0 и 2.0 он превратился из того, к чему я готовился перейти, в то, к чему я не могу перейти. Так что да, я бы сказал, что он не готов. ASP.NET — это способ показать нужные мне биты через HTTP. ASP.NET — это не то, что мне нужно само по себе. Я использую .NET не только для веб-сайтов, я использую его для платформы... как и очень многие люди. Платформа не готова к широкому спектру вариантов использования, которые требуются пользователям, поэтому принуждение пользователей к этой платформе вызывает боль и блокировку.

Суть в том, что если нам нужна аутентификация AD ( огромная часть платформы), мы просто отказались от линии 1.x. Вот куда я направился с нашими приложениями... но если это направление, то нет смысла прилагать усилия, пока нужные мне биты не будут доступны в пункте назначения.

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

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

Одна вещь, с которой я лично борюсь, — это «стабильная платформа» против «новых функций». С одной стороны, мы хотим, чтобы платформа была стабильной, надежной и совместимой, с другой стороны, никто не хочет оставаться на 1.x, потому что в ней нет функций 2.x. Есть ли в ASP.NET Core 2.x очень привлекательные функции, которые тянут людей в этом направлении, или это просто тот факт, что у нас больше функций, чем у нас было в 1.x (потому что это ново и блестяще)?

Если последнее, то заботятся ли эти люди о стабильности? Если да, то почему недостаточно ASP.NET Core 1.x?

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

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

Если последнее, то заботятся ли эти люди о стабильности? Если да, то почему недостаточно ASP.NET Core 1.x?

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

Есть ли в ASP.NET Core 2.x очень привлекательные функции, которые тянут людей в этом направлении, или это просто тот факт, что у нас больше функций, чем у нас было в 1.x (потому что это ново и блестяще)?

Поддержка - это то, за что мы платим.

Если да, то почему недостаточно ASP.NET Core 1.x?

Потому что поддержка заканчивается примерно через год после выпуска (по словам Скотта выше). К тому времени я едва закончу портирование Stack Overflow.

как это связано с отказом ASP.NET Core 2.x от поддержки .NET Framework?

Потому что библиотек , которые мне нужны, там нет. И я не знаю, когда они будут. Так что я бы застрял на 1.x, и у меня есть бомба замедленного действия, пока не закончится поддержка. Будет ли у меня достаточно времени для переноса с 1.0 на 2.x (или 3.x) до прекращения поддержки? Возможно нет.

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

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

В настоящее время мое мнение таково: есть новая платформа, которая работает примерно до июля 2018 года. После этого: я ничего не знаю, я просто надеюсь , что к тому времени то, что мне нужно, будет доступно на netstandard / netcoreapp . И надеюсь, что у меня будет достаточно времени для переноса до окончания поддержки. Однако мне платят не за надежду, а за то, что я принимаю решения о платформе для нашей компании, и ASP.NET Core — плохой выбор (для нас) с этим изменением и отсутствием даты выпуска версии, которая будет работать.

Позвольте мне подвести итог: без поддержки .NET Full Framework ASP.NET Core не предлагает поддерживаемую платформу для наших вариантов использования в течение следующих 2 лет.

В сокращенной версии это так:

Приоритет 1: Это должно работать на net461 , независимо от того, какие там ifdefs, perf.
Приоритет 2. Если вы можете сделать это в 10 раз быстрее на .NET Core 2.0, это здорово. Это отличная причина для людей выбрать платформу и/или мигрировать, когда они могут.

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

Приоритет 1: Это должно работать на net461

И если бы .NET Core был полностью совместим с net461 (в пределах разумного); поэтому все, что написано для net461, работало на Core; тогда это будет нормально?

По сути, в этот момент у вас есть более стабильная платформа, чем net4x, поскольку вы можете работать бок о бок и автономно (также коснитесь x-plat). В то время как у net461 есть изменения всей машины до 4.6.1, 4.6.2, 4.7 и т. д.

Очевидно, что-то никогда не сработает; как частичное доверие - но это все равно никогда не работало.

Реальный вопрос: ASP.NET Core 1.x в настоящее время поддерживает .NET Framework и .NET Core. Допустим, это была стабильная платформа, которую вы упомянули выше, которую мы исправили и поддерживали в обеих средах выполнения, но не получили дополнительных функций. Будет ли этого достаточно?

Я бы хотел увидеть LTS-релиз ASP.NET Core 2.0, как Ubuntu / Redhat со своими LTS-релизами, которые они поддерживают более 5 лет. Это обеспечит прочную совместимую цель, которую остальная часть экосистемы может с уверенностью взять на себя.

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

Разве у нас не было бы такого же обсуждения через год? Может быть, к тому времени экосистема или библиотеки, поддерживающие .NET Core, станут больше, и это окажет меньшее влияние? А как насчет тех корпоративных библиотек, которые никогда не будут обновляться (или исходный код которых был утерян)? Изменятся ли они через год?

В идеальном мире .NET v4.x и .NET Core будут поддерживать ASP.NET Core в обозримом будущем, и только новые функции .NET Core будут доступны только в пакетах только для .NET Core. Но если MS суждено оставить .NET 4.x позади, то выпуск ASP.NET 2.0 LTS до того, как вы официально расстанетесь, будет следующим лучшим решением. По определению никто не зависит от новых функций, которых еще не существует, поэтому никто не будет вынужден переходить на версию 3.0, предназначенную только для .NET Core.

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

Во-первых, спасибо @davidfowl за то, что вскочил в тему и встал/задал вопросы и т. д. Когда есть разгоряченное сообщество, задающее кучу вопросов, легко не вмешаться и не стать «мишенью». Так что спасибо за конструктивное участие. /me приветствует вас.

Я вижу два основных момента/потока, вытекающих из этого разговора:

1. Запрос на поддержку рабочего стола .NET во vnext. (это 99% ответов здесь)
2. Отсутствие консультаций с общественностью по такому важному решению. (2 или 3 ответа здесь).

TL;ДР;

• Можем ли мы быть более открытыми с большими важными изменениями в следующем.
• Выделите некоторое время для некоторых RFC от сообщества об этих vnext изменениях.

@mythz хорошо сказал об этом в своем вступительном предложении к своему (на данный момент) ~самому последнему~ 2-му самому последнему комментарию:

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

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

Так что я чувствую, что с новым направлением, которое взяла MS (OSS-все-вещи и т. д.) и с некоторыми недавними мега-убер-.NET-потоками за последние 12/18 месяцев (читай: изучение опыта этих дискуссий в сообществе ) ... что «мы» все вместе в этом и что некоторые из этих Действительно Больших Вещей ™️ будут обсуждаться открыто, намного раньше времени.

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

Примечание. Я согласен с тем, что этот проект (проекты) не является демократическим и что _решения_ принимаются MS. Нет проблем. Я не критикую _that_. Я говорю о шагах, предшествовавших этому. Кроме того, я не прошу, чтобы _все_ выставлялось для RFC и т. д. Просто нечетный важный пункт заявки - вроде того, с чего началась эта ветка.

Но если MS суждено оставить .NET 4.x позади, то выпуск ASP.NET 2.0 LTS до того, как вы официально расстанетесь, будет следующим лучшим решением. По определению никто не зависит от новых функций, которых еще не существует, поэтому никто не будет вынужден переходить на версию 3.0, предназначенную только для .NET Core.

Я не понимаю. Никто еще не зависит от функций ASP.NET 2.0, так как они не существуют в выпуске. Так не является ли эта версия ASP.NET Core 1.x? Он работает на полной платформе, ядрах 1.0 и ядрах 2.0 и может служить ступенькой к ASP.NET Core 2.x?

@onovotny

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

Да, но действительно трудно гарантировать тот же уровень качества, когда .NET Framework является большой стабильной поддержкой, привязанной к компоненту ОС. Как сказал @terrajobst , некоторые вещи определенно будут портированы в какой-то момент, но с другими нужно будет разобраться. Дело в том, что ASP.NET Core лучше всего работает на .NET Core, потому что у нас есть возможность сразу обновить весь стек. На данный момент существуют большие различия в производительности между двумя средами выполнения, и нам еще предстоит использовать зависимости от новых API-интерфейсов из-за поддержки .NET Framework. По мере продвижения вперед мы будем добавлять новые API, которые могут появиться или не появиться в .NET Framework в какой-то момент, и мы не хотим обновляться в темпе самой стабильной и самой медленной среды выполнения (.NET Framework).

@НикКравер

Потому что поддержка заканчивается примерно через год после выпуска (по словам Скотта выше). К тому времени я едва закончу портирование Stack Overflow.

Я не уверен, что это совсем точно. Когда будет доступна версия 2.0, версия 1.1 будет по-прежнему поддерживаться. Так о какой "поддержке" вы говорите? Вы имеете в виду платную поддержку или вы имеете в виду, что мы исправим проблемы, когда они возникнут?

Потому что библиотек, которые мне нужны, там нет. И я не знаю, когда они будут. Так что я бы застрял на 1.x, и у меня есть бомба замедленного действия, пока не закончится поддержка. Будет ли у меня достаточно времени для переноса с 1.0 на 2.x (или 3.x) до прекращения поддержки? Возможно нет.

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

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

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

В настоящее время мое мнение таково: есть новая платформа, которая работает примерно до июля 2018 года. После этого: я ничего не знаю, я просто надеюсь, что к тому времени то, что мне нужно, будет доступно на netstandard/netcoreapp. И надеюсь, что у меня будет достаточно времени для переноса до окончания поддержки. Однако мне платят не за надежду, а за то, что я принимаю решения о платформе для нашей компании, и ASP.NET Core — плохой выбор (для нас) с этим изменением и отсутствием даты выпуска версии, которая будет работать.

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

Приоритет 1: Это должно работать на net461, независимо от того, какие там ifdefs, perf.
Приоритет 2. Если вы можете сделать это в 10 раз быстрее на .NET Core 2.0, это здорово. Это отличная причина для людей выбрать платформу и/или мигрировать, когда они могут.

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

Единственная причина, по которой .NET Framework работает так хорошо, как сегодня, заключается в том, что мы намеренно поддерживали его. Это не бесплатно, это не «просто быстрее на ядре», нам пришлось специально проектировать систему так, чтобы можно было заставить ее работать на .NET Framework. Даже если вы этого еще не видите, разрыв между функциями будет увеличиваться, как только мы решим (и мы решили) использовать зависимости от API, которых еще нет в .NET Framework. Мы можем сделать то, что говорит @PinpointTownes , и начать выбрасывать NotSupportedException , когда появятся эти пробелы в функциях, но IMO, это довольно плохой опыт.

Мы потратили большой бюджет на разработку, чтобы перенести наше приложение ASP.net MVC5 на полную платформу ядра ASP.net, чтобы оно хорошо работало с Azure Service Fabric. Весь проект растянулся на несколько месяцев, в течение которых несколько недель было посвящено переносу нашего веб-приложения (и, честно говоря, борьбе с неуклюжими инструментами VS2015).

Единственная причина, по которой это сработало, заключалась в том, что поддерживалась полная структура, поскольку в настоящее время мы используем SignalR на ядре ASP.net (к разочарованию @davidfowl ). Насколько я могу судить, SignalR по-прежнему не поддерживается в Asp.net Core?

Затем мы потратили неделю или около того на переход на новый инструментарий VS2017. Отлично.

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

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

Во-первых, получить все, что под брендом Microsoft, что люди используют сегодня в полной структуре ASP.net core, работает только на ядре ASP.net. Во-вторых, выясните, что еще (если вообще что-то) может помешать экосистеме принять ядро ​​ASP.net по желанию. Тогда и только тогда прекратите поддержку Netfx, как это обсуждается.

Мы можем сделать то, что говорит @PinpointTownes , и начать генерировать NotSupportedException, когда появятся эти пробелы в функциях, но IMO, это довольно плохой опыт.

Это не совсем то, что я сказал: при кросс-компиляции ifdefs определенно должен быть предпочтительным вариантом для исключения API, недоступных на конкретной платформе, но если по какой-либо причине вы абсолютно ДОЛЖНЫ иметь эту подпись API в общедоступном контракт, то вы можете пойти с NotSupportedException .

Я не понимаю. Никто еще не зависит от функций ASP.NET 2.0.

Я ожидаю, что большинство разработчиков ждут стабильной и высокосовместимой версии .NET Standard 2.0, которую поддерживают их зависимости, прежде чем переходить на ASP.NET Core. Они не захотят внедрять .NET Core 1.1 теперь, зная, что он был EOL'ed, а у MS нет хорошей истории предоставления долгосрочной поддержки какой-либо старой версии DNX/.NET Core. Если бы существовал высокосовместимый стабильный выпуск LTS, который остальная часть экосистемы могла бы безопасно принять, у предприятий должно было бы быть все необходимое для запуска на нем своих систем, и они не чувствовали бы себя обязанными обновляться до .NET Core vNext, поскольку у них было бы все, что им нужно. нуждаются в версии 2.0, и когда придет время, будет намного проще спланировать их миграцию с ASP.NET Core 2.0/.NET v4.6 на будущую версию только для .NET Core.

@миф

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

Согласен со всем там, но я не вижу, как это решение повлияет на то, что вы сказали. Я хочу все то же самое 👍 .

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

Верно, разве это не ASP.NET Core 1.x? Если бы поддержка была расширена на 1.x, разве этого не было бы достаточно? Мы могли бы просто убедиться, что ASP.NET Core 1., который является сетевым стандартом 1.x, работает на .NET Core 2.0 (что уже работает) и поддерживать его, скажем, еще год или около того.

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

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

@davidfowl Совершенно правильные вопросы - ответы:

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

Активные исправления для проблем — будут ли 1.x получать исправления для всех вещей, которые мы сломаем, или нам будет предложено обновиться для исправления в некоторых случаях? (примечание: это обновление, которое мы не можем сделать, пока не появятся наши библиотеки, такие как DirectoryServices... и даже если мы сможем , оно далеко не бесплатное или даже дешевое, скорее всего, это займет как минимум несколько месяцев). Мы большие, мы быстрые, мы найдем бреши в рамках. У нас есть для каждого основного и дополнительного выпуска в течение многих лет. Поддержка имеет решающее значение для нас.

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

Нет, мне нужна работающая версия и путь вперед. С 1.x у нас есть только первая половина. До этого выпуска предполагалось второе.

Как на это влияют обновленные версии ASP.NET Core?

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

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

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

Значит, еще одного года достаточно для всех?

Абсолютная продолжительность на самом деле не имеет значения - это должна быть совместимость вариантов использования + время (IMO). Если бы наши варианты использования работали сегодня (например, авторизация через AD), то 2 года хватит, да. Но в настоящее время это не так, поэтому соглашаться с тем, что произвольный момент времени с этого момента допустим, в лучшем случае преждевременно.

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

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

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

Как руководитель архитектуры/платформы, я должен решать, какие ставки мы делаем. В настоящее время это плохая ставка. Когда версия 1 поддерживает вас, а версия 2 — нет, но , надеюсь, когда-нибудь будет , это действительно плохая игра с чужим временем и деньгами. По крайней мере, для нас мы выбрали .NET из-за функций, экосистемы и поддержки. В настоящее время в новом слове мы перешли от всех 3 из них к 1. Экосистемы еще нет (поверхность API, библиотеки), и поддержка намного короче, чем мы привыкли, без какого-либо гарантированного пути обновления и неизвестное количество времени, чтобы сделать это.

@jahmai

Единственная причина, по которой это сработало, заключалась в том, что поддерживалась полная структура, поскольку в настоящее время мы используем SignalR на ядре ASP.net (к разочарованию @davidfowl ). Насколько я могу судить, SignalR по-прежнему не поддерживается в Asp.net Core?

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

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

Есть ли функции, которые вам нужны в ASP.NET Core 2.0? Или вы просто предполагаете, что в конечном итоге вам нужно будет перейти на следующее ядро ​​​​ASP.NET, и в этот момент все не будет работать на .NET Framework?

Во-первых, получить все, что под брендом Microsoft, что люди используют сегодня в полной структуре ASP.net core, работает только на ядре ASP.net. Во-вторых, выясните, что еще (если вообще что-то) может помешать экосистеме принять ядро ​​ASP.net по желанию. Тогда и только тогда прекратите поддержку Netfx, как это обсуждается.

В рамках netstandard 2.0 была проделана большая работа по определению важных API-интерфейсов, которые необходимо вернуть, чтобы библиотеки, ориентированные на .NET Framework, были по большей части совместимы с ним в двоичном виде. Конечно, есть области, которые просто не будут работать, такие как WCF, WPF и т. д., но это поможет, поскольку мы провели некоторые исследования, и ~ 60% библиотек API-совместимы с netstandard 2.0 (поправьте меня, если я ошибаюсь в этом числе). @terrajobst) и может работать только на .NET Core 2.0.

Верно, разве это не ASP.NET Core 1.x? Если бы поддержка была расширена на 1.x, разве этого не было бы достаточно?

Я ожидал, что .NET Standard 2.0 станет стабильной платформой, обеспечивающей совместимость с .NET 4.x, поэтому имеет смысл поддерживать LTS вокруг нее. Никто не ожидает, что 1.1/.NET v4.x будет EOL в середине выпуска, поэтому было бы уважительно объявить LTS в последней версии, когда она будет выпущена, а не отключать поддержку .NET 4.x до ее выпуска, нет- один делает LTS в ретроспективе старых версий, подобных этой.

Я знаю, что мы поддерживаем наши пакеты .NET Core в отдельных пакетах *.Core , поэтому мы можем оставаться в отдельной каденции выпуска, которая следует за последней версией .NET Core, поскольку момент, когда мы объединяемся с основными пакетами NuGet, это означает мы обязуемся выпустить стабильную версию, которую собираемся официально поддерживать, поэтому мы должны быть уверены, что у нас есть версия, которую мы сможем поддерживать в обозримом будущем, чего я ожидал от .NET Standard 2.0, а не от текущего .NET Standard. Смесь 1,1/1,3/1,6. Я помню также, что было время, когда должен был быть выпуск 1.7/8 с временным разрывом, который был несовместим с 2.0, нарушающим ожидания в отношении версий .NET Standard, которые не являются сигналами стабильной платформы.

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

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

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

Есть ли функции, которые вам нужны в ASP.NET Core 2.0? Или вы просто предполагаете, что в конечном итоге вам нужно будет перейти на следующее ядро ​​​​ASP.NET, и в этот момент все не будет работать на .NET Framework?

В какой-то момент я хочу перейти на netstandard2 по причинам. Мне нужно будет переместить мое веб-приложение на asp.net core 2 для этого, верно?

В рамках netstandard 2.0 была проделана большая работа по определению важных API-интерфейсов, которые необходимо вернуть, чтобы библиотеки, ориентированные на .NET Framework, были по большей части совместимы с ним в двоичном виде. <...>

Конечно, и мне нравится то, что делается с помощью netstandard, но если в netstandard чего-то не хватает, вы можете обойти это, потому что вы можете использовать полную структуру в приложениях, которые в ней нуждаются. Теперь у нас есть несколько чистых библиотек netstandard 1.3 (наш исходный код), которые используются совместно: Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1, потому что мы можем дополнить отсутствующую функциональность в netstandard специальными библиотеками, предназначенными для фреймворка, включая net46. в нашем основном веб-приложении asp.net.

Единственная причина, по которой у нас есть эти сетевые библиотеки, заключается в том, что нам нужно было портировать наше огромное веб-приложение (как я упоминал ранее). Я хотел бы, чтобы не нужно было расширять кодовую базу нашей платформы для других платформ, а вместо этого продолжать двигаться вверх по цепочке сетевых стандартов. Я действительно не хочу застревать на netstandard 1.3, потому что нет пути для перехода на asp.net core 2.

Активные исправления для проблем — будут ли 1.x получать исправления для всех вещей, которые мы сломаем, или нам будет предложено обновиться для исправления в некоторых случаях? (примечание: это обновление, которое мы не можем сделать, пока не появятся наши библиотеки, такие как DirectoryServices... и даже если мы сможем, оно далеко не бесплатное или даже дешевое, скорее всего, это займет как минимум несколько месяцев). Мы большие, мы быстрые, мы найдем бреши в рамках. У нас есть для каждого основного и дополнительного выпуска в течение многих лет. Поддержка имеет решающее значение для нас.

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

Нет, мне нужна работающая версия и путь вперед. С 1.x у нас есть только первая половина. До этого выпуска предполагалось второе.

Это просто означает, что вам нужно оставаться на 1.x, пока все ваши зависимости не будут перенесены, нет?

@NickCraver Все ваши жалобы касаются вещей, отсутствующих в .NET Core, а не в ASP.NET Core. В .NET Core 1.x и ASP.NET Core 1.x эти две сущности поставляются вместе, но полностью не связаны. Я не слышал ни одной причины для использования ASP.NET Core 2.0, кроме обоснованных опасений, что v1 что-то поддерживает, а v2 не поддерживает. Я думаю, что у нас было бы то же самое обсуждение через год, если бы была другая причина, по которой вы не смогли перенести только на .NET Core (возможно, во время разработки ASP.NET Core на полной платформе вы взяли некоторые новые зависимости, которые никогда не будет портирован в качестве примера).

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

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

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

@миф

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

Конечно, но, как я уже сказал, ASP.NET Core, .NET Core и .NET Standard в версии 1.x полностью не связаны. Вы можете использовать любую библиотеку .NET Standard в любой версии .NET Core, которая ее поддерживает. Так что, если .NET Core 2.0 — это новая LTS, мы все равно можем объявить, что ASP.NET Core 1.x поддерживается на ней.

@jahmai

В какой-то момент я хочу перейти на netstandard2 по причинам. Мне нужно будет переместить мое веб-приложение на asp.net core 2 для этого, верно?

Нет, это неправильно. Вы можете перейти на netstandard 2 в любое время, не перенося веб-приложение на ASP.NET Core 2.0.

Единственная причина, по которой у нас есть эти библиотеки netstandard, заключается в том, что нам нужно было портировать наше огромное веб-приложение (как я упоминал ранее). Я хотел бы не расширять кодовую базу нашей платформы для других платформ, а вместо этого продолжать двигаться вверх по цепочке сетевых стандартов. Я действительно не хочу застревать на netstandard 1.3, потому что нет пути для перехода на asp.net core 2.

Вам не нужно зацикливаться на netstandard 1.3. 2 вещи не связаны.

Когда версия 1 поддерживает вас, а версия 2 — нет, но _надеюсь, когда-нибудь будет_, это действительно плохая игра...

В этом, я думаю, суть вопроса. Мы получили комментарии о том, что _некоторые_ пробелы ( DirectoryService и др.) известны и будут устранены. Нам нужно что-то более конкретное, чем это.

Я согласен с ASP.NET Core, нацеленным на .NET Core, и с тем, что нам не хватает лодки 2.0, если дорожная карта ясна, когда мы можем ожидать, что эти пробелы (и какие пробелы) будут устранены (опять же, при условии, что есть достаточно времени для переноса, прежде чем 1.X становится неподдерживаемым).

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

@davidfowl

Нет, это неправильно. Вы можете перейти на netstandard 2 в любое время, не перенося веб-приложение на ASP.NET Core 2.0.

Превосходно. В этом случае, пока Microsoft обеспечивает поддержку версии 1.x (все виды исправлений ошибок и оперативная поддержка), пока не предложит клиентам надлежащий путь миграции на версию 2.x (например, SignalR), я спокойно выжидаю, пока мы нужно asp.net ядро ​​2.

Это просто означает, что вам нужно оставаться на 1.x, пока все ваши зависимости не будут перенесены, нет?

Правильно, но это должен быть известный период времени. У нас нет дат, единственное, что нам пока сказали, это «не в 2.0»… так что это нехорошо. Например, System.DirectoryServices запрашивается с середины 2015 года, и до сих пор отсутствует, но часто повторяется как наиболее востребованный пользователями (за ним следует System.Drawing ). Заявление о том, что мы доводим .NET Standard 2.0 до примерно 60% паритета API, но отсутствие частей, о которых просили пользователи, наверняка посылает смешанные сигналы о том, что важно.

Все ваши жалобы касаются вещей, отсутствующих в .NET Core, а не в ASP.NET Core.

Это неправильно. Мне нужны биты, которые нам нужны для запуска (например, аутентификация AD) на поддерживаемой платформе. Не хватает поддержки от последнего. Поддержка 1.x, безусловно, моя главная забота. У нас нет поддерживаемого пути вперед или каких-либо сроков, когда мы можем его ожидать.

Я думаю, что у нас будет точно такая же дискуссия через год

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

Если DirectoryServices, Drawing и т. д. появятся в версии 2.x, то это будет здорово. Этот выпуск должен поддерживать .NET Framework и быть выпуском LTS. И 3.x должен отказаться от полной поддержки фреймворка.

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

Справедливо, но все это безумие вторично по отношению к вопросу «а оно вообще работает?». В настоящее время это фирма нет. ASP.NET и .NET Core/Standard/что угодно может быть двумя наборами вещей внутри Microsoft (и я это полностью понимаю), но для разработчиков это по-прежнему одна платформа. Стороне ASP.NET нужны API, которые будут полезны многим, а их пока нет. Этот шаг еще больше сокращает количество доступных API. Команда ASP.NET может получить то, что им нужно, но за счет того, что нам нужно.

@ctolkien @NickCraver

В этом, я думаю, суть вопроса. Мы получили комментарии о том, что некоторые пробелы (DirectoryService и др.) известны и будут устранены. Нам нужно что-то более конкретное, чем это.

Правильно, но это должен быть известный период времени. У нас нет дат, единственное, что нам сказали, это «не в 2.0»… так что это нехорошо. Например, System.DirectoryServices запрашивается с середины 2015 года и до сих пор отсутствует, но часто повторяется как наиболее востребованный пользователями (за ним следует System.Drawing).

Однако эти пробелы связаны с самим .NET Core, и я могу понять тревогу, не зная, когда эти зависимости будут доступны, и поэтому помочь нам расставить приоритеты для них было бы хорошо. Хорошей новостью является то, что netstandard 2.0 и netcoreapp2.0 положили начало групповой работе, чтобы упростить портирование других библиотек. Я ожидаю, что после того, как мы выпустим 2.0, будет намного проще установить другие зависимости, перенеся куски кода поверх нашей очень совместимой базы.

Будет ли CSOM работать в netcore 2? Это было бы огромным препятствием для нас и одной из областей, о которой я ничего не слышал.

@davidfowl Я тоже искренне надеюсь, что это так, но я не ставлю на это нашу компанию. С отказом от поддержки до того, как это произойдет, а не после, я категорически не согласен. Я думаю, что это происходит в период времени 3.x после того , как эти критические API для многих потребителей будут созданы, и это абсолютно правильно. Делая это до того, как они будут готовы, мы просто останавливаем наше усыновление.

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

@НикКравер

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

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

Это неправильно. Мне нужны биты, которые нам нужны для запуска (например, аутентификация AD) на поддерживаемой платформе. Не хватает поддержки от последнего. Поддержка 1.x, безусловно, моя главная забота. У нас нет поддерживаемого пути вперед или каких-либо сроков, когда мы можем его ожидать.

Какой компонент ASP.NET отсутствует для этого сценария? Когда вы говорите 1.x против 2.x, было бы полезно, если бы вы упомянули ASP.NET Core против .NET Core.

Если DirectoryServices, Drawing и т. д. появятся в версии 2.x, то это будет здорово. Этот выпуск должен поддерживать .NET Framework и быть выпуском LTS. И 3.x должен отказаться от полной поддержки фреймворка.

Я упоминал об этом ранее, какие функции ASP.NET Core вам нужны, а ASP.NET Core 1.x недостаточно для этого?

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

Согласен, но нам нужно прояснить FUD в этом обсуждении, чтобы мы могли правильно оценить влияние. ASP.NET Core 1.x предназначен для .NET Standard 1.x (1.0–1.6) и .NET Framework 4.5.1. Это означает, что он может работать на любой платформе, которая поддерживает эти версии netstandard и .NET Framework. Это означает, что ASP.NET Core 1.x будет работать на .NET Core 2.0.

@смбекер

Будет ли CSOM работать в netcore 2? Это было бы огромным препятствием для нас и одной из областей, о которой я ничего не слышал.

Я понятия не имею, что это такое. Это https://msdn.microsoft.com/en-us/library/ff798388.aspx? Если это так, то не было проделано никакой работы для его явной поддержки. Это может работать только на основе совместимости с .NET Framework в .NET Core 2.0, но я предполагаю, что он никогда не будет перенесен в .NET Core (только на основании моих 5 минут просмотра), но я могу ошибаться.

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

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

Какой компонент ASP.NET отсутствует для этого сценария? Когда вы говорите 1.x против 2.x, было бы полезно, если бы вы упомянули ASP.NET Core против .NET Core.

Я упоминал об этом ранее, какие функции ASP.NET Core вам нужны, а ASP.NET Core 1.x недостаточно для этого?

Я имею в виду поддержку последнего ядра ASP.NET, поддерживающего Full Framework (и, следовательно, нужные мне библиотеки). Я надеюсь , что это 2.x, так как нам нужны модули, бритвенные страницы и т. д. У нас есть применение многим функциям 2.x. Но похоже, что наш единственный вариант на данный момент — это 1.x. Мы не можем совершить переход с ASP.NET 5 на ASP.NET Core и с полного фреймворка со всеми нашими рабочими библиотеками на netcoreapp за 1 шаг. Это слишком много. Это слишком дорого. Это слишком рискованно. И теперь мы не уверены, сможем ли мы сделать этот дорогостоящий и рискованный шаг в окне поддержки. Плохая ситуация - настолько плохая, что лучше не двигаться (по состоянию на сегодняшний день). Я думаю, что это действительно неудачно.

Какой компонент ASP.NET отсутствует для этого сценария? Когда вы говорите 1.x против 2.x, было бы полезно, если бы вы упомянули ASP.NET Core против .NET Core.

• Если нет способа обрабатывать аутентификацию/запросы AD через какой-либо пакет Microsoft.Authentication.* NuGet, то это одна большая вещь. В настоящее время я нахожусь в той же лодке, но, поскольку я использую .NET Core 1.1 поверх .NET 462, я смогу это осуществить. Помимо этого, как я смогу запрашивать любые группы AD, метаданные с помощью поддерживаемых средств? Я видел в репозитории corefx, что над System.DirectoryServices выполняется много работы, так что я, по крайней мере, рад этому.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . В настоящее время я могу получить к нему доступ только при работе на .NET Core поверх полной .NET Framework. Я думаю, это больше удобно, так как я все еще могу использовать DbDataReader / SqlDataReader .

В основном мне нужно знать, что будет гарантия НЕКОТОРОГО поддерживаемого способа обработки аутентификации AD при использовании ASP.NET Core 2.x без необходимости полной .NET Framework.

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

Я все еще немного застрял в случае использования пакетов ASP.NET Core на netstandard . До этого выпуска я предполагал (возможно, ошибочно), что netstandard де-факто является целью библиотек. Другими словами, предполагаемое поведение авторов библиотек будет состоять в том, чтобы нацеливаться на netstandard , если только для этого не будет необходимой и убедительной причины. Это обеспечивает совместимость не только с Framework, но и с другими платформами, такими как Xamarin и UWP. Работа над .NET Standard 2.0, казалось, поддерживала это, пытаясь унифицировать поверхность API различных сред выполнения в общую цель, о которой не нужно думать.

Для меня это изменение сигнализирует о чем-то другом. Конечно, в конце концов, ASP.NET Core — это просто библиотека, и, возможно, у нее есть «необходимые и веские причины», чтобы не поддерживать общую область поверхности netstandard . Но это также одна из наиболее заметных библиотек .NET, разработанных Microsoft, и, говоря: «Нам нужна самая последняя и самая лучшая, поэтому мы собираемся прекратить поддержку netstandard », она сигнализирует всем разработчикам других библиотек (или в по крайней мере, для меня), что, возможно, им следует перестать так усердно поддерживать netstandard и просто начать ориентироваться на среду выполнения Core. Зачем заморачиваться со всеми этими вещами совместимости, если Microsoft даже не особо заботится об этом? .NET Core 4 жизни. И, возможно, это к лучшему — это определенно отличается от того, что я думал, что мы собирались с несколькими средами выполнения и в основном унифицированной поверхностью API.

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

Наконец, я несколько (хотя и немного меньше) обеспокоен комментариями здесь о том, что, как только это станет возможным, в Core будут добавлены новые API для проверки в сочетании с ASP.NET. В частности, эти новые API могут никогда не попасть в netstandard или .NET Framework. Я, конечно, понимаю, что могут быть некоторые интересные вещи, которые можно сделать, если отбросить или ослабить проблемы с наследием и совместимостью. Но, честно говоря, у меня сложилось впечатление, что команда ASP.NET Core часто вырывается вперед. Это не обязательно плохо, но это также привело к ряду более широких решений, от которых пришлось отказаться. Я не могу не задаться вопросом, не приведет ли это и последующая быстрая эволюция среды выполнения Core к значительному разрушению набора сред выполнения с течением времени (и опять же, не только Windows/Framework останется позади — есть также Xamarin, Mono, UWP и т. д.).

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

@НикКравер

Я имею в виду поддержку последнего ядра ASP.NET, поддерживающего Full Framework (и, следовательно, нужные мне библиотеки). Я надеюсь, что это 2.x, так как нам нужны модули, бритвенные страницы и т. д. У нас есть применение многим функциям 2.x.

Сейчас 1.1.1 (в 2.0 модулей нет), Razor Pages хороший, еще SignalR. Это две вещи, которые я считаю наиболее болезненными.

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

Это все же? Переход с ASP.NET Core 1.x на 2.x или 3.x при условии, что ваши зависимости были перенесены, будет тривиальным. Если вы планируете перейти на ASP.NET Core в целом, переход на 1.1 — это хороший первый шаг, и вы не сэкономите на работе, избегая этого.

@сниклер

В основном мне нужно знать, что будет гарантия НЕКОТОРОГО поддерживаемого способа обработки аутентификации AD при использовании ASP.NET Core 2.x без необходимости полной .NET Framework.

Пока System.DirectoryServices не поддерживается в .NET Core, есть ли причина, по которой вы не можете использовать ASP.NET Core 1.x в .NET Framework?

Пока System.DirectoryServices не поддерживается в .NET Core, есть ли причина, по которой вы не можете использовать ASP.NET Core 1.x в .NET Framework?

Это то, что я сейчас делаю. Я просто с нетерпением жду в надежде, что мне не придется беспокоиться о .NET Framework, если мне это не нужно. В настоящее время это ограничивает меня моей машиной с Windows, поскольку пространство имен System.DirectoryServices.AccountManagement не существует в Mono. В том же отношении, будут ли доступны System.DirectoryServices.AccountManagement за пределами ограничений Windows? Этот маленький кусочек заставляет меня переключаться между машинами во время локальной отладки моего проекта MVC и моего приложения Xamarin.iOS.

Если вы планируете перейти на ASP.NET Core в целом, переход на 1.1 — это хороший первый шаг, и вы не сэкономите на работе, избегая этого.

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

Я продолжаю ссылаться на DirectoryServices, потому что знаю , что сегодня это не работает с netcoreapp2.0 . Конечно, будут и другие вещи, которые попадут в ту же лодку. Нужен ASP.NET Core + полный фреймворк + поддержка несколько лет на какой-то платформе. С 1.x мы не получаем большого прироста, на самом деле мы получаем очень мало. Производительность не является отличным аргументом, поскольку мы уже отображаем страницы примерно за 18 мс, и это ничтожно мало из-за времени транспортировки. 2.0, однако, предлагает довольно много хороших вещей. Страницы Razor и перспектива плагинов делают его очень привлекательным для переноса. Настолько, чтобы быть оправданным.

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

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

Что касается небольшого разглагольствования по OT, я хотел бы знать, как вы можете отображать страницы за ~ 18 мс @NickCraver . Это потрясающе

@daveaglick

Я все еще немного застрял в случае использования пакетов ASP.NET Core в netstandard. До этого выпуска я предполагал (возможно, ошибочно), что де-факто целью библиотек был netstandard. Другими словами, предполагаемое поведение авторов библиотек будет заключаться в том, чтобы нацеливаться на netstandard, если только для этого не будет необходимой и убедительной причины. Это обеспечивает совместимость не только с Framework, но и с другими платформами, такими как Xamarin и UWP. Работа над .NET Standard 2.0, казалось, поддерживала это, пытаясь унифицировать поверхность API различных сред выполнения в общую цель, о которой не нужно думать.

Здесь ничего не изменилось. На самом деле куча наших библиотек, которые мы хотим запускать на других платформах , все еще являются сетевыми стандартами. Если вы перечитаете что-то из вышеперечисленного:

• Microsoft.Extensions.* (Журналирование, DI, конфигурация, FIleProviders и т. д.)
• EntityFramework
• Клиенты SignalR (они должны работать на .NET Framework, Xamarin, UWP и т. д.).

.NET Standard — это де-факто способ написания библиотек, которые работают везде. Авторы библиотек должны по возможности ориентироваться на netstandard, чтобы получить максимально широкий охват платформы. Авторы библиотек должны решить, хотят ли они иметь охват или нет. Вот почему такие библиотеки, как JSON.NET, поддерживают netstandard1.x и .NET framework 2.0. Они делают все возможное, чтобы все «просто работало», как упоминалось выше @JamesNK .

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

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

Я предполагаю, что они все еще являются нетстандартными. Какие из них не являются?

Я не могу не задаться вопросом, не приведет ли это и последующая быстрая эволюция среды выполнения Core к значительному разрушению набора сред выполнения с течением времени (и опять же, не только Windows/Framework останется позади — есть также Xamarin, Mono, UWP и т. д.).

Я думаю, что netstandard будет развиваться, но .NET Framework всегда будет последним, кто получит новые API (Xamarin и Mono довольно быстро добавляют новые вещи).

@сниклер

Это то, что я сейчас делаю. Я просто с нетерпением жду в надежде, что мне не придется беспокоиться о .NET Framework, если мне это не нужно. В настоящее время это ограничивает меня моей машиной Windows, поскольку пространство имен System.DirectoryServices.AccountManagement не существует в Mono. В том же отношении будет ли доступен System.DirectoryServices.AccountManagement за пределами ограничений Windows? Этот маленький кусочек заставляет меня переключаться между машинами во время локальной отладки моего проекта MVC и моего приложения Xamarin.iOS.

Убедитесь, что вы регистрируете подобные проблемы в dotnet/corefx. Предполагать, что ваши зависимости будут перенесены (если только они не пользуются бешеной популярностью), неправильно.

@davidfowl Вопрос: я хочу Файл -> Новый проект с ASP.NET Core 2.0 и пройти аутентификацию в AD. Будет ли это возможно? Я просто не могу представить платформу Microsoft без такой возможности.

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

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

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

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

@davidfowl Спасибо - ваш комментарий очень помогает. Я (очевидно, неправильно) понял, что большинство/все вспомогательные библиотеки уходят с netstandard как часть этого изменения. Я использую довольно много, и знаю других, которые тоже так делают, поэтому услышать, что это не так, — приятная новость.

@NickCraver , какую аутентификацию вы используете сегодня против AD? OpenIdConnect, WsFed, NTLM, другое?

Аутентификация @Tratcher AD через DirectoryServices (нам нужно запросить членство в группе и т. Д. - стандартные биты)

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

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

• ASP.NET Core 2.x является LTS и последним, который поддерживает Full Framework (конечно, поскольку мы уже были в предварительной версии, вы не слишком далеко ушли), а также SignalR, поддерживающий его позже в этом году, так что это целевая платформа для совершения скачка с ASP.NET на ASP.NET Core
• 3.x отказывается от поддержки Full Framework и выпускается при переносе основных зависимостей.

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

Ради забавы я попробовал использовать EntityFramework 6, который, как я видел, широко используется в приложениях ASP.NET Core 1.0, над которыми я работал, — с последними ночными сборками .NET Core preview2. Угадай, что...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

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

Что абсолютно ужасно, так это то, что вы поймете, что это не работает только во время выполнения. В некоторых случаях это даже не будет заметно. Например, SqlClient в .NET Core не поддерживает ни зачисление внешних транзакций, ни распределенные транзакции с TransactionScope : даже если вы найдете способ заставить EF 6 работать, ваши TransactionScope s вообще не будет эффективным, и ваши вызовы БД не будут использовать необходимый вам уровень изоляции.

Я считаю необходимым добавить свои пять копеек в отношении моего беспокойства по поводу этого шага. У нас есть настольное приложение, которое в основном представляет собой Windows Forms с некоторыми новыми областями, разработанными в WPF. Над этим приложением работали более 15 лет, и потребуются годы, чтобы полностью отказаться от WinForms. Я бы хотел, чтобы это было не так, но это так. Мы работали над созданием большей модульности в кодовой базе, чтобы мы могли использовать уровни бизнеса и доступа к данным через новый веб-интерфейс и существующее приложение WinForms. Я намеревался очень скоро перейти на ASP.NET Core для нашего нового веб-приложения, но, как я только что сказал, мне нужно будет использовать большую часть нашей существующей кодовой базы, ориентированной на .NET v4.6.x. Я точно знаю, что мы используем System.Drawing и System.Security.Cryptography. Мы также активно используем TransactionScope описанными выше способами.

Я с нетерпением ждал возможности воспользоваться некоторыми преимуществами ASP.NET Core, такими как возможность инкапсулировать области нашего веб-приложения в отдельные сборки без необходимости полагаться на MEF для объединения всего этого. Есть много дополнительных причин, но именно эта делает его действительно приятным. Однако, если я переведу наше приложение на ASP.NET Core, я, вероятно, застряну на 1.x в обозримом будущем, потому что нам нужно поддерживать переносимость нашего внутреннего кода с помощью WinForms. Я сосредоточился главным образом на веб-продукте, поэтому я не могу сказать вам, где мы подключаемся к таким вещам, как WMI и т. д., и влияет ли это на вопрос переносимости, но я знаю, что мы находимся в рамках нашей кодовой базы. Сейчас мы находимся в действительно интересной фазе, и последнее, что я хочу сделать, — это разработать все веб-версии наших функций на ASP.NET MVC 5 и накопить кучу нового устаревшего кода, который нужно будет портировать в какой-то момент. будущее стремление.

Я уверен, что у нас будет много применений, которые будут удерживать нас от ориентации на .NET Standard, даже если/когда мы больше не будем использовать WinForms. Мы являемся партнером Microsoft и работаем напрямую с Microsoft над нашим продуктом несколькими способами, поэтому я не хочу вдаваться в подробности того, чем мы здесь занимаемся, но я был бы рад провести более приватное обсуждение с @ shanselman или @davidfowl , если вам нужна дополнительная информация о том, что мы делаем. Я также собираюсь быть на MS Build и мог бы встретиться и поговорить с любым из вас там, если вы будете присутствовать.

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

Муахаха. Не знаю, смеяться мне или плакать...

Вот отчет, созданный инструментом анализа ApiPort для моего тривиального 23-строчного приложения EF 6, которое не работает:

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

До того, как этот вопрос был открыт, был ли процесс обратной связи?

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

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

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

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

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

@рохатсу

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

Что, если бы SignalR работал на ASP.NET Core 1.x? Что еще незрелого в платформе, которая вам нужна?

@millman82 Спасибо, что поделились этим. Похоже , вы застряли бы на версии до того, как поддержка .NET Framework на некоторое время была прекращена. Таким образом, некоторые из предложений здесь, где мы сохраняем совместимость с 2.x, а 3.x отбрасывается, могут даже не сработать для вас. Почему бы просто не остаться на ASP.NET Core 1.x? Чего в нем не хватает, что нужно в вашем порту? Или это та же проблема, что и у @NickCraver (то, что 2.x не поддерживает его, заставляет вас нервничать, делая на него ставку).

@jkells

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

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

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

Часть его по-прежнему нацелена на netstandard, как уже несколько раз упоминалось в этой ветке.

Почему бы просто не остаться на ASP.NET Core 1.x?

Вы не можете — он не поддерживается через 1 год после выпуска 2.0 (при условии, что 2.0 — это следующая LTS).

@davidfowl Это определенно большая часть этого. Мы также используем OData и SignalR в нашем текущем веб-приложении, и это должно быть в ASP.NET Core, прежде чем мы сможем перейти. Однако единственное, чего я не хочу, — это застрять в подвешенном состоянии, когда будет прекращена поддержка ASP.NET Core 1.x и не будет пути миграции с используемыми нами частями фреймворка, которые в настоящее время не поддерживаются. Я предвижу, что ASP.NET Core полностью заменит ASP.NET. Он может быть где-то в будущем, но он приближается. Зная, что мне бы не хотелось переписывать наш пользовательский интерфейс сейчас в ASP.NET MVC 5 (сейчас у нас есть несколько вещей, но его легко переместить, потому что он маленький) только для того, чтобы через несколько лет снова переписать его в ASP.NET Core как только наступит конец жизни ASP.NET.

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

@ctolkien

Вы не можете — он не поддерживается через 1 год после выпуска 2.0 (при условии, что 2.0 — это следующая LTS).

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

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

Замените 1.x на 2.x в этом предложении. Вы думаете, что через год все ваши зависимости будут портированы?

Замените 1.x на 2.x в этом предложении. Вы думаете, что через год все ваши зависимости будут портированы?

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

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

Почему он выпал из поддержки? В моем гипотетическом мире мы бы дольше поддерживали ASP.NET Core 1.x на .NET Framework.

Почему он выпал из поддержки? В моем гипотетическом мире мы бы дольше поддерживали ASP.NET Core 1.x на .NET Framework.

У меня вопрос, сколько еще? Кроме того, достаточно ли велика команда, чтобы перенести необходимые зависимости, такие как SignalR и OData, в ASP.NET Core 1.x и поддерживать поддержку до тех пор, пока все эти отсутствующие зависимости не будут фактически перенесены? Похоже, это опровергает высказанные ранее аргументы о том, почему вы хотите отказаться от полной поддержки .NET сейчас. Честный вопрос...

У меня вопрос, сколько еще? Кроме того, достаточно ли велика команда, чтобы перенести необходимые зависимости, такие как SignalR и OData, в ASP.NET Core 1.x и поддерживать поддержку до тех пор, пока все эти отсутствующие зависимости не будут фактически перенесены? Похоже, это опровергает высказанные ранее аргументы о том, почему вы хотели бы отказаться от полной поддержки .NET сейчас. Честный вопрос...

Я выкину случайное число, 3 года. Команда ASP.NET не владеет интеграцией Odata, это делает команда Odata, поэтому я не могу отвечать за них. Что касается SignalR, я думаю, что можно было бы ориентироваться на ASP.NET Core 1.x.

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

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

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

Задействуйте экосистему, чтобы узнать, что это за список (нет, этот выпуск не для этого). Если это зависимость, принадлежащая Microsoft, перенесите ее. Если это не так, обратитесь к владельцу, чтобы сообщить ему о планах и помочь с руководством по миграции (если он ничего не делает, это не вина Microsoft). За время, необходимое для выполнения этого процесса, поддержите ASP.net core 1.x. Я не вижу другого способа достичь твоих целей, не расстроив множество людей. Это большое предложение, которое требует высокого уровня заботы и внимания, чтобы сделать все правильно.

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

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

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

Суть в том, что мы увлечены этим, потому что хотим его использовать.

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

У нас много клиентов и новых разработчиков, которые никогда в жизни не видели .NET. Мы должны обслуживать всех, потому что это то, что мы пытаемся делать как Microsoft. Люди, работающие на .NET Framework, знают, любят и понимают, как это работает, поэтому убедитесь, что вы понимаете, что ASP.NET Core работает на .NET Framework, но как новый разработчик, приближающийся к платформе, я надеюсь никогда не упоминать об этом, поскольку это запутывает историю по сравнению с что-то вроде go или node (которые на данный момент практически не имеют наследия).

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

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

Я вижу несколько популярных идей в этой теме от:

• Я хочу, чтобы вы всегда поддерживали .NET Framework.
• Я хочу, чтобы вы поддерживали .NET Framework до тех пор, пока не будут перенесены зависимости, которые мне нужны для моего приложения.
• Мне просто нужен еще 1 год, этого времени будет достаточно, чтобы отказаться от поддержки .NET Framework (ASP.NET Core 3.x).

А еще то, что мы не написали объявление (это наша вина), но оно будет (обещаю, я виню выходные).

Я также не знаю, как выглядит паритет API для большинства людей здесь, я предполагаю, что у разных людей он разный. .NET Framework — это надежная, надежная корпоративная технология, которой более 15 лет, и она привязана к Windows.
.NET Core был создан для написания современных облегченных кроссплатформенных микросервисов и постепенно развивался, чтобы быть более совместимым, чтобы упростить перенос библиотек. Тем не менее, я не знаю, что значит подходить к .NET Framework с точки зрения совместимости и является ли это вообще целью (изначально ее не было). В какой-то момент вы не сможете использовать ASP.NET Core поверх .NET Framework, и возникнет некоторая непереписываемая зависимость, несовместимая с .NET Core. Приложения должны будут учитывать это при разработке с учетом ASP.NET Core (в ближайшем будущем).

Что касается проектов, над которыми я работаю, гораздо более длительный период поддержки версии 1.1 был бы достойным смягчением последствий. Маловероятно, что мы сможем отказаться от зависимостей netfx за 1 год, но гораздо более вероятно, что +3 года, которые вы предложили в качестве соломенного человека. Было бы очень неплохо сначала выпустить релиз, в котором все сошлось бы на уровне 2.0 — это тот момент, когда все должно было стать легче портировать! Я говорю только от имени одной организации, но «2.0 будет выпуском LTS; 3.0 отключит netfx» будет для нас обычным делом, а не поводом для FUD.

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

Что касается паритета, я ранее предполагал, что ядро ​​.net никогда не приблизится к уровням совместимости .net framework, но это нормально, потому что ядро ​​​​asp .net будет продолжать поддерживать оба.

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

Проспав над ним ночь -

Лично я считаю хорошей идеей оставить старый фреймворк .net и написать лучший веб-фреймворк для современной среды выполнения.

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

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

+1

Лично я считаю хорошей идеей оставить старый фреймворк .net и написать лучший веб-фреймворк для современной среды выполнения.

Я полностью согласен. Я надеялся, что это будет постепенное изменение, например, Kestrel отказывается от поддержки сначала для perf (остается хостинг на основе http.sys), затем mvc/* для улучшения API и функциональности, в то время как начинаются усилия по портированию / тестированию совместимости для netstandard2.0.

Превосходно. В этом случае, пока Microsoft гарантирует, что 1.x поддерживается (все виды исправлений ошибок и> оперативная поддержка), пока она не предложит клиентам правильный путь миграции 2.x (например, SignalR), тогда я> комфортно жду своего времени пока нам не понадобится asp.net core 2.

+1

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

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

@dasMulli

Я полностью согласен. Я надеялся, что это будет постепенное изменение, например, Kestrel отказывается от поддержки сначала для perf (остается хостинг на основе http.sys), затем mvc/* для улучшения API и функциональности, в то время как начинаются усилия по портированию / тестированию совместимости для netstandard2.0.

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

@gulbanana

Было бы очень неплохо сначала выпустить релиз, в котором все сошлось бы на уровне 2.0 — это тот момент, когда все должно было стать легче портировать! Я говорю только от имени одной организации, но «2.0 будет выпуском LTS; 3.0 отключит netfx» будет для нас обычным делом, а не поводом для FUD.

Зачем вам ASP.NET Core 2.0 (забудьте .NET Standard и .NET Core 2.0)?

Нам особо не нужны возможности asp.net core 2.0. Я бы очень хотел иметь более простые процессы сборки и взаимодействия, которые приходят с волной 2.0. Будет ли asp.net core 1.1, если он работает на netcoreapp2.0, использовать библиотеки netstandard2.0? Будет ли это считаться «стандартным» и поддерживаемым сценарием, а не чем-то, что никто не тестирует и на что никто не обращает внимания?

По сути, если 1.1 станет LTS, я беспокоюсь о том, что проблемы будут закрыты через восемнадцать месяцев с «ну, вы можете сделать это с помощью API 2.0».

Нам особо не нужны возможности asp.net core 2.0. Я бы очень хотел иметь более простые процессы сборки и взаимодействия, которые приходят с волной 2.0. Будет ли asp.net core 1.1, если он работает на netcoreapp2.0, использовать библиотеки netstandard2.0? Будет ли это считаться «стандартным» и поддерживаемым сценарием, а не чем-то, что никто не тестирует и на что никто не обращает внимания?

Конечно, это сработает. Как я уже говорил, сегодня эти 3 вещи полностью разъединены. Вот пример проекта, в котором выполняется ASP.NET Core 1.1 в .NET Core 2.0 с использованием версии API System.Configuration, перенесенной в пакет .NET Standard 2.0:

https://github.com/davidfowl/AspNetCore1OnNetCore2

Я был бы счастлив принять это, если бы между .NET Core и .NET Framework был автоматический уровень взаимодействия (не текущий, который может генерировать исключения во время выполнения, и не самодельные внутренние вызовы WebAPI) — какая-то оболочка («WowNET»?), что заставит нас хранить код, зависящий от 4.6, в отдельных .dll, но позволит запускать устаревшие версии за счет снижения производительности (что в случае LOB-приложений не является главной проблемой). Как вы думаете, это было бы технически возможно?

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

По сути, если 1.1 станет LTS, я беспокоюсь о том, что проблемы будут закрыты через восемнадцать месяцев с «ну, вы можете сделать это с помощью API 2.0».

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

@рохатсу

Я был бы счастлив принять это, если бы между .NET Core и .NET Framework был автоматический уровень взаимодействия (не текущий, который может генерировать исключения во время выполнения, и не самодельные внутренние вызовы WebAPI) — какая-то оболочка («WowNET»?), что заставит нас хранить код, зависящий от 4.6, в отдельных .dll, но позволит запускать устаревшие версии за счет снижения производительности (что в случае LOB-приложений не является главной проблемой). Как вы думаете, это было бы технически возможно?

Вроде этого https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root , но для .NET Core и .NET Framework. Мы сделали что-то очень похожее, когда ASP.NET поддерживали Helios, прокладку .NET Framework, которая использовалась для ускорения coreclr в IIS. Хаки, чтобы заставить его работать, были довольно уродливыми, хотя это была смесь COM и передачи структур в метод Main через string[] args. Хотя технически все возможно. Я не уверен, какую точность вы ожидаете, поскольку они не являются одной и той же средой выполнения, и вы не можете передавать объекты туда и обратно. Вы также будете запускать 2 GC, 2 Jits и больше dll в одном и том же процессе, и я не уверен, что вы получаете, делая что-то вне процесса.

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

Далеко от. .NET Framework развивается и поставляется вместе с Windows, поскольку является компонентом Windows. Мы только что выпустили .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/), а также множество новых функций. Дело в том, что .NET Core может и будет поставляться быстрее, потому что он не привязан ни к чему другому, поэтому API, runtime-функции и т. д. появятся там в первую очередь. Это не означает, что со временем вещи не перейдут к .NET Standard и .NET Framework. Просто добираться туда будет дольше. Тот факт, что .NET Framework обновляется на месте, является причиной того, что мы так осторожны при переносе изменений. Любое изменение может привести к поломке любого приложения, когда обновление автоматически загружается на миллиард компьютеров 😉 . С .NET Core платформа работает параллельно, поэтому приложениям необходимо выбрать более новую версию, чтобы получить новые функции или исправления. Там просто больше свободы.

Просто чтобы взвесить библиотеки net4x, которые мы сейчас используем в ASP.NET Core 1.x, они не будут работать в версии 2.0: EntityFramework 6. В EFCore просто отсутствуют многие недостающие функции, которые мы используем (например, перехватчики/перехватчики жизненного цикла). Итак, мы застряли на EF6 на некоторое время.

И, согласно сообщению @PinpointTownes , EF6 не работает с текущей (находящейся в разработке) версией ASP.NET Core 2.x.

@nphmuller , тогда вы будете продолжать использовать ASP.NET Core 1.x до тех пор, пока не будет перемещено больше зависимостей (я не знаю, сколько вещей вам требуется от EF Core и каков статус).

@davidfowl Конечно, если за это время не пройдет окно поддержки от ASP.NET Core 1.x.
Основная фишка — перехват (хуки жизненного цикла). Другие недостающие функции могут быть проще для нас. Перехват у них в бэклоге, но не привязан к релизу. И моя интуиция подсказывает мне, что это не будет реализовано какое-то время.

@gulbanana : Я думаю, что как сообщество мы в основном используем ядро ​​​​.net для использования ядра asp.net, а не по его собственным достоинствам.

Говори за себя. Для некоторых из нас основным преимуществом .NET Core является отказ от Windows на сервере.

И, я полагаю, все вы, грязные хиппи, владеющие Маками. 😝

@bradwilson И, я полагаю, все вы, грязные хиппи, владеющие Mac.

Говори за себя, некоторые из нас не хиппи ;P

Но да, выход из Windows (или, на самом деле, IIS и http.sys) — это то, что я хочу от .NET Core наряду с развертыванием xcopy, производительностью и т. д.

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

@PinpointTownes — это справочная ошибка, что произойдет, если вы сошлетесь на System.Configuration в соответствии с https://github.com/aspnet/Home/issues/2022#issuecomment -299810945? EF6 говорит, что у него нет зависимостей, потому что все находится в старом пакете GAC/Full Framework.

@benaadams и @PinpointTownes причина его сбоя в том, что System.Configuration.ConfigurationManager не является именем DLL, которое ожидает .NET Framework. Я не уверен, что порт System.Configuration действителен.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Да, возможность запуска серверов, отличных от Windows, — это здорово и очень важно… но без ядра asp.net что бы вы на них запускали? Даже Нэнси для ядра .net использует ядро ​​​​asp.net через kestrel, UseOwin() и т. д.

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

Это нечестно, мы следуем дорожным картам, а вы раньше об этом ничего не говорили!!
Если вы сказали это раньше, мы не будем использовать ASP.NET Core в нашем проекте, потому что нам нужны .NET 4.x Libs.
Наше планирование включает в себя обновление наших проектов до ASP.NET Core 2 из-за необходимых новых функций.
Нам также нужен ASP.NET Core 2 для работы с .NET 4.x. если нет возможности, то как насчет поддержки ASP.NET Core 1.x, планируете ли вы добавить в нее все новые функции или просто исправление ошибок.

Наше планирование включает в себя обновление наших проектов до ASP.NET Core 2 из-за необходимых новых функций.

Какие?

@PinpointTownes — это ошибка ссылки. Что произойдет, если вы сошлетесь на System.Configuration согласно #2022 (комментарий)?

Добавление <Reference Include="System.Configuration" /> не имеет никакого эффекта (т. е. генерируется то же самое исключение), поскольку кажется, что оно не может быть разрешено из GAC (хотя не уверен, что это действительно удивительно):

Я не уверен, что порт System.Configuration действителен.

Итак, официальный вывод: вы не можете использовать библиотеку, написанную для .NET Framework 4.x, в .NET Core, если она использует System.Configuration ?

@PinpointTownes Я даже не уверен, что поставляется версия System.Configuration (та, что в упаковке). Может быть, это так, а может и нет (это обсуждение, которое нужно начать с corefx). Я просто говорю вам, почему ваш образец сломался именно так.

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

Насколько я знаю, по умолчанию ссылки GAC в проектах SDK не поддерживаются. См. https://github.com/dotnet/sdk/issues/987#issuecomment -286307697, чтобы узнать, как его включить.

Итак, официальный вывод: вы не можете использовать библиотеку, написанную для .NET Framework 4.x, в .NET Core, если она использует System.Configuration?

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

@davidfowl спасибо за ответ
Некоторые необходимые функции и помощники в EF Core запланированы в версии 2.0, особенно для сопоставления данных (сопоставления автономных типов)...
В любом случае, мне нужно просто иметь четкое представление о дорожной карте ASP.NET Core 1.x, наша команда в замешательстве и беспокойстве.

Одна вещь, с которой я лично борюсь, — это «стабильная платформа» против «новых функций». С одной стороны, мы хотим, чтобы платформа была стабильной, надежной и совместимой, с другой стороны, никто не хочет оставаться на 1.x, потому что в ней нет функций 2.x. Есть ли в ASP.NET Core 2.x очень привлекательные функции, которые тянут людей в этом направлении, или это просто тот факт, что у нас больше функций, чем у нас было в 1.x (потому что это ново и блестяще)?

@davidfowl Я действительно думаю, что signlarR - одна из таких функций, по крайней мере, в моем предыдущем проекте. Однако я также думаю, что большая часть беспокойства связана с относительно короткими окнами поддержки для 1.1 (2018?), Если бы люди были уверены, что смогут работать на asp.net 1.1, пока они не будут готовы перейти на ядро, то есть потенциально годы и также прикрыть патчами, которые немного успокоили бы людей.

Я также думаю, что поддержку asp.net core 1.1 в .net core 2.0 стоит выделить еще больше, это дает людям (как я думаю) хороший путь миграции: asp.net 5 на 46 > asp.net core 1.x на 46 > asp.net core 1.x на .net core 2.0> asp.net core 2 на .net core 2. Это был бы путь, который снизил бы риск, о котором беспокоятся многие люди.

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

Я понимаю причину отказа от полной/настольной платформы .NET. Черт, я даже согласен, что это способ расширить возможности ASP.NET, НО я не вижу, как это решается сейчас, а не с самого начала.

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

Я не вижу, как это решается сейчас, а не с самого начала.

По предположению:

В .NET Core 1.x нельзя было запускать библиотеки Full framework, так что это был бы полный прорыв.

В .NET Core 2.x вы в основном можете запускать полную структуру и можете запускать библиотеки .NET Standard 1.x–2.0, так что это не является серьезным прорывом.

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

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

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

С помощью ASP.NET Core 1 мы разрабатываем наши современные сервисы, ориентируясь на стандарт .NET для Libs и выбирая развертывание на зависимостях Full .NET или .NET Core для каждой службы.

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

_На .NET Core 2.x вы в основном можете запускать полную структуру и можете запускать библиотеки .NET Standard 1.x–2.0, так что это не является серьезным прорывом._

@benaadams Существует большая разница между возможностью использовать большую часть BCL и возможностью использовать библиотеки, которые были созданы для Full .NET (и внутри могут использовать неподдерживаемые функции в .NET Standard 2.0 / унификация типов).

Я предполагаю, что это решение не повлияет на упрощение перехода на ASP.NET Core 2.0 с ASP.NET 4?
Довольно много приложений, которыми я управляю, могли бы действительно извлечь выгоду из обновления до ASP.NET Core 2.0, но, поскольку для ASP.NET Core нет поддержки OWIN/Katana, я думаю, мне нужно выполнить миграцию вручную, а это слишком много работы. @damianh предложил подобное в https://github.com/aspnet/AspNetKatana/issues/27 .

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

Насколько я понимаю, теперь мы не сможем перейти на asp.net core 2.0 и получить сигнал, когда он выйдет.

Мы путешествовали со времен dnx, от RC1 до RC2 и от проекта json до csproj, и, наконец, нам показалось, что мы вышли из леса ... теперь не так уж и много.

Я могу понять, что это изменение в конечном итоге произойдет, но действительно ли сейчас время сделать это, когда ядро ​​​​asp.net пытается набрать обороты? Кроме того, моя интуиция подсказывает мне, что EF Core еще недостаточно зрелый (и, конечно, не для пространственных), и любой, кто делает ставку на поддержку в ядре, берет на себя больший риск в отношении переноса библиотек... похоже, ожидание другой версии для этого перехода это дало бы некоторую стабильность и шанс для EF Core и других портов наверстать упущенное, не говоря уже о сигнале r на полном фреймворке.

Бьюсь об заклад, большая часть предприятия использует ядро ​​​​asp.net (что, кстати, здорово) на полной платформе и вполне может оказаться в таком же положении, как и мы.

Учитывая этот переход на скоростной поезд для ASP.NET Core, означает ли это, что вы представите версию LTS и Current, и какова будет продолжительность поддержки для этих экземпляров?

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

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

Это изменение делает заявление, которое я не уверен, что оно мне нравится: это нормально, чтобы ориентироваться только на netcoreapp.

Я тоже хотел написать свое мнение.

Я считаю, что еще слишком рано отказываться от .net framework. Я не знаю, в чем проблема совместной поддержки .net framework + .net core, но я считаю, что это решение немного усложнит переход на AspNet Core. Потому что некоторые компании думают, что: «Давайте начнем AspNet Core с ядром .net. Если у нас возникнут серьезные проблемы (например, необходимая библиотека не будет поддерживать его в будущем), мы всегда можем вернуться к .net framework». Но теперь это будет невозможно, и компании будут колебаться, стоит ли начинать с AspNet Core. Кроме того, это решение может снизить значение .netstandard.

@hikalkan

Потому что некоторые компании думают, что: «Давайте начнем AspNet Core с ядром .net. Если у нас возникнут серьезные проблемы (например, необходимая библиотека не будет поддерживать его в будущем), мы всегда можем вернуться к .net framework».

Вы всегда можете использовать ASP.NET Core 1.1, верно?

Кроме того, это решение может снизить значение .netstandard.

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

Конечно, они могут использовать asp.net core 1.1. Но нехорошо говорить: «Последняя версия ASP.NET Core — 2.x, но вам следует использовать ASP.NET Core 1.x, если вы хотите ориентироваться на .net framework». Это не сильно отличается от того, чтобы сказать «используйте MVC 5.x» :)

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

Вы всегда можете использовать ASP.NET Core 1.1, верно?

нет явного преимущества. Во-первых, он еще не созрел, так что это ставка.
Во-вторых, разработчики ASP.Net Core не захотят писать в старых инструментах и ​​оставаться позади.
Меня интересует несколько вещей.

1. Мы работаем уже в новом проекте полностью в ASP.Net Core, Dapper и т.д.
   Но в других проектах наша бизнес-логика в сборках 4.6. Как я читал выше, у нас не должно возникнуть проблем со ссылкой на них. Надеюсь, я хорошо понял о.
2. СигналР. DirectoryServices, MS Orleans, Azure.
3. возможно, это не имеет отношения к приведенному выше разговору, но я безумно хочу разместить локально ASP.Net Core с Kestrel или другим HttpListener в качестве настольного приложения UWP или в качестве настольного моста в UWP.

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

В июле моя команда начинает работу над новым 12-18-месячным проектом, который будет работать на ASP.NET Core 2.0 со всеми интересными вещами, о которых мы читали в течение многих лет в .NET Core.

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

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

Прежде чем я выскажу свое мнение, я хотел бы внести ясность в одну часть.
Буду ли я прав, если предположу, что если мы хотим продолжать использовать ASP.NET Core,
мы не сможем ссылаться на dll, предназначенные для .Net 4.5 или выше, и заставить их работать так, как сейчас?

@ louislewis2 Нет, это неправильно. Вы сможете использовать библиотеки от net45 net461 , пока они остаются в поддерживаемом пространстве API за netstandard2.0 . Вам не нужно будет перекомпилировать эти библиотеки.

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

Сейчас очень полегчало :)

@shanselman @DamianEdwards @davidfowl В вашем списке элементов, которые мы используем, но которые еще не были перенесены, будут элементы в dll system.management. Мы специально используем идентификаторы оборудования, они используются для автоматического создания ссылок для служебной шины Azure и всего нашего сервера лицензирования и клиентского пакета. Я полагаю, что если они в настоящее время не являются API, это вызовет у нас серьезные проблемы?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

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

Это ставит нас в неловкое положение.

Я нахожусь в процессе переноса наших микросервисов с ASP.Net 4.5, размещенных в процессе самостоятельно поверх Kestrel (причины устаревшей совместимости), на полностью размещенные самостоятельно ASP.Net Core 1.x. Тем не менее, нам нужно запустить эти вещи на полной основе, на данный момент. И на это есть веские причины.

У нас есть ряд жестких зависимостей Windows, которые уже являются частью нашей инфраструктуры и не подлежат изменению. Это включает аутентификацию NTLM, ведение журнала событий и т. Д. Если ASP.Net Core 2.x отказывается от поддержки netstandard, то я могу вообще не делать этого. Проблема в том, что нет активно разрабатываемой полной альтернативы фреймворку. Катана мертвая и медленная (для сравнения).

Если бы кто-нибудь мог указать мне HTTP-сервер, который работает так же быстро, как Kestrel для .Net Framework, тогда конечно. Но этого не существует. Так что я просто должен признать, что ASP.Net оставляет реальных клиентов, таких как я, позади с этим изменением.

Если стеку нужны все новые возможности, такие как Pipelines и Span, то они должны быть предоставлены в виде сетевых стандартных библиотек. Какие API использует ASP.Net Core 2.x из netcoreapp2.0, которых нет в netstandard2.0, и почему эти API нельзя сделать библиотеками расширений netstandard2.0?

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

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

@mattnischan

Я нахожусь в процессе переноса наших микросервисов с ASP.Net 4.5, размещенных в процессе самостоятельно поверх Kestrel (причины устаревшей совместимости), на полностью размещенные самостоятельно ASP.Net Core 1.x. Тем не менее, нам нужно запустить эти вещи на полной основе, на данный момент. И на это есть веские причины.

Вы можете продолжать использовать ASP.NET Core 1.x, верно?

Если стеку нужны все новые возможности, такие как Pipelines и Span, то они должны быть предоставлены в виде сетевых стандартных библиотек. Какие API использует ASP.Net Core 2.x из netcoreapp2.0, которых нет в netstandard2.0, и почему эти API нельзя сделать библиотеками расширений netstandard2.0?

Когда в .NET Standard появятся API, которых нет в .NET Framework, как вы собираетесь их использовать?

@stefan2410

Вы можете использовать ASP.NET Core 1.x для этого, верно? Какие функции ASP.NET Core 2.0 вам нужны? Это просто SignalR?

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

Еще раз, в моем гипотетическом мире мы продлеваем жизнь 1.x

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

Вам действительно нужен ASP.NET Core 2.0? Или только .NET Core 2.0?

Когда в .NET Standard появятся API, которых нет в .NET Framework, как вы собираетесь их использовать?

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

@davidfowl
Я перейду на ASP.Net core 2.0. У меня нет другого решения. Я не могу сказать команде оставаться в стороне от эволюции, мы долго ждали ASP.Net Core.
Поскольку у нас нет проблем с нашей бизнес-логикой 4.6 ссылок на сборки.
Мне нужны SignalR, DirectoryServices, а не проблемы с библиотеками Azure/Amazon, MS Orleans.
Также, возможно, это не имеет отношения к приведенному выше разговору, но я хочу, чтобы настольное приложение размещало локально ASP.Net Core с Kestrel / HttpListener в качестве настольного приложения UWP или в качестве настольного моста в UWP.
Мы не можем переписать код для XAML, и я не хотел бы использовать Electron.

Вы можете продолжать использовать ASP.NET Core 1.x, верно?

На какой срок? Я не вижу, чтобы что-то вроде журнала событий соответствовало сетевому стандарту.

Когда в .NET Standard появятся API, которых нет в .NET Framework, как вы собираетесь их использовать?

Это вещь? Согласно документации, netstandard20 все еще работает на net461. Вы говорите, что API в netstandard20 недостаточно совершенен для реализации новых возможностей? Или есть какой-то план вывести netstandard за рамки, которые еще не разглашаются?

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

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

• .NET Standard будет развиваться со скоростью самой медленной реализации
• .NET Standard будет развиваться другими темпами, и .NET Framework догонит его последним.

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

Также, возможно, это не имеет отношения к приведенному выше разговору, но я хочу, чтобы настольное приложение размещало локально ASP.Net Core с Kestrel / HttpListener в качестве настольного приложения UWP или в качестве настольного моста в UWP.

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

Я хочу воспользоваться моментом, чтобы поблагодарить всех за их комментарии и отзывы здесь. Мы действительно ценим это, а также ваше терпение, пока мы выясняем путь вперед. Пожалуйста, знайте, что мы не планировали, чтобы это изменение было таким жестким, таким запоздалым и без предупреждения. Ретроспектива — это 20/20, и если бы мы знали то, что знаем сейчас, мы бы сообщали об этом раньше. Будем стараться двигаться дальше.

У нас есть план, основанный на отзывах, которые мы получили здесь, и я хочу поделиться с вами, прежде чем опубликовать его в качестве объявления позже на этой неделе с выпуском 2.0.0-preview1. Когда это произойдет, мы откроем новую тему, чтобы облегчить обсуждение этого плана, но пока продолжайте делиться своими мыслями и отзывами здесь:

• Поддержка ASP.NET Core 1.x в .NET Framework будет продлена как минимум еще на год (до июля 2019 г.). Мы будем пересматривать это ежегодно и обязуемся предоставлять уведомление за 12 месяцев до прекращения поддержки ASP.NET Core 1.x (поэтому к июлю 2018 года мы объявим, продлеваем ли мы еще 12 месяцев до июля 2020 года) ( Примечание: кого-нибудь еще напугал тот факт, что мы уже говорим о 2020 году? Нет? Хорошо, только я. )
• Новый SignalR будет полностью поддерживаться в ASP.NET Core 1.x (появится позже в этом году).
• Мы продолжим обновлять ASP.NET Core 1.x для поддержки новых языковых версий и т. д., как мы это делаем для System.Web
• ASP.NET Core 1.x, работающий на .NET Core 1.x, будет поддерживаться до июля 2018 г. (без изменений).
• ASP.NET Core 1.x, работающий на .NET Core 2+, будет поддерживаться до тех пор, пока поддерживается ASP.NET Core 1.x на .NET Framework.
  
  
  
  • Это делается для того, чтобы поддерживаемое ядро ​​ASP.NET всегда перекрывалось с поддерживаемым ядром .NET, в то время как мы поддерживаем работу в .NET Framework, что позволяет клиентам со временем выполнять перенос, оставаясь на поддерживаемых битах.
  
  
• Поддержка .NET Core 1.x (в качестве среды выполнения) не изменится. Заканчивается в июле 2018 г. Клиентам, использующим ASP.NET Core 1.x, необходимо перейти на .NET Core 2.0 или использовать .NET Framework в этот момент (или перейти на ASP.NET Core 2.0 в .NET Core 2.0).
• В этом году мы перенесем System.DirectoryServices и System.Drawing на .NET Core (полная поддержка, кроссплатформенность, предварительная версия по крайней мере для Windows летом)
• Список того, что после этого нужно портировать на .NET Core, в настоящее время включает ServiceBase (для поддержки .NET Core Windows Services). Пока нет временной шкалы, кроме следующей (временные рамки, очевидно, становятся более конкретными по мере того, как мы работаем по списку). Мы будем дополнять этот список по мере продвижения, основываясь на отзывах клиентов.
• В настоящее время у нас нет планов портировать System.ServiceModel (серверный WCF) на .NET Core. WCF для .NET Core может продолжать улучшаться и добавлять функции на основе отзывов, например, шифрование HTTP-сообщений.

@DamianEdwards @davidfowl большая часть проблемы заключается в том, что это может занять месяцы планирования и усилий разработчиков, при этом жертвуя огромными альтернативными затратами, чтобы перейти на ASP.NET Core, когда многие организации не смогут перейти с него. .NET 4.x, поскольку это единственная платформа, в которой они могут быть уверены, что они смогут запускать все свои системные зависимости.

До этого момента MS агрессивно рекламировала .NET Core как будущее ASP.NET, где неясно, остановилась ли разработка ASP.NET 4.x и будут ли все будущие усилия разработчиков вложены в ASP.NET Core, поэтому будет много миграций, чтобы поддерживать их системы в актуальном состоянии. Многие люди почувствуют себя брошенными под автобус, если в результате всех своих усилий они эффективно перейдут на платформу EOL. Это повредит как организациям, так и разработчикам/консультантам, которые были самыми активными сторонниками перехода на .NET Core. Возможно, сейчас им ничего не нужно из ASP.NET Core 2.0, но они определенно захотят иметь некоторый запас для своих систем и получить доступ к некоторым новым функциям для всех своих усилий.

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

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

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

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

Здесь по-прежнему существует огромный фундаментальный разрыв. Порт на 1.х почти полностью боковой, фич в нем для нас мало. 2.x — это то место, где есть некоторые полезные обновления, и у нас все еще нет гарантии, что мы когда-либо сможем это сделать. Существует большая вероятность того, что мы потратим значительное количество времени, денег и усилий на перенос на 1.x только для того, чтобы застрять там из-за полной зависимости от фреймворка. Я не буду играть в эту игру с нашей компанией. Мы вполне можем получить меньшую поддержку, чем сейчас в ASP.NET 4.x.

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

Я искренне надеюсь, что вы пересмотрите это решение. Я надеюсь, что однажды мы сможем заставить Stack Overflow воспользоваться тысячами личных часов, которые мы посвятили разработке платформы .NET Core.

@НикКравер

Существует большая вероятность того, что мы потратим значительное количество времени, денег и усилий на перенос на 1.x только для того, чтобы застрять там из-за полной зависимости от фреймворка.

На протяжении всей этой темы вы называли System.DirectoryServices одной из основных вещей. Я предполагаю, что у вас есть некоторые зависимости, перенос которых, по вашему мнению, займет много времени, или такие, которые никогда не будут перенесены. Если бы 2.0 поддерживал .NET Framework, эти зависимости переместились бы через год?

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

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

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

Я ничего не знаю о stackoverflow.com, но можно ли отломать части (я не хочу говорить «микросервисы»), чтобы можно было использовать ASP.NET Core для некоторых частей?

@миф

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

Вы имели в виду ядро ​​ASP.NET? Или .NET Core?

@davidfowl Я имел в виду ASP.NET Core, но это также влияет на разработчиков, которые планировали поэтапную миграцию сначала с ASP.NET Core/.NET 4.x, а затем с .NET Core.

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

@davidfowl Я имел в виду ASP.NET Core, но это также влияет на разработчиков, которые планируют поэтапную миграцию сначала с ASP.NET Core .NET 4.x, а затем с .NET Core.

Я не понимаю, почему это так.

Я думаю, что этого плана, вероятно, будет достаточно для моей организации, чтобы избежать ухода с платформы. Главное иметь более длительный период поддержки (=патчи безопасности), в течение которого оставшиеся deps netfx могут быть переписаны или иным образом устранены. Однако все это по-прежнему довольно рискованно и концептуально странно. Что произойдет, если через три года мы захотим создать веб-сайт, который может принимать документы Excel, или встроить веб-сервер в приложение? Что происходит с другими фреймворками, такими как Orleans, построенными на основе стандарта вместо netcoreapp?

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

Что произойдет, если через три года мы захотим создать веб-сайт, который может принимать документы Excel

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

или встроить веб-сервер в приложение?

HttpListener является частью netstandard 2.0.

Что происходит с другими фреймворками, такими как Orleans, построенными на основе стандарта вместо netcoreapp?

Фреймворки сами решают, хотят ли они работать на .NET Framework, UWP, .NET Core, моно и т. д. Это выбор. Orleans не поставляется с .NET Core. ASP.NET Core делает. Это одни и те же продукты.

Что будет трудным решением для нас (и наших клиентов), касается не библиотек, которые у меня есть сегодня, а библиотек, которые, я не знаю, понадобятся ли мне через 6 месяцев. Существует множество библиотек и фреймворков, которые еще не поддерживают netstandard . Например, за месяц работы над проектом мы поняли, что нам нужно несколько функций в NHibernate, которых даже близко не было в EF6, не говоря уже о EF Core. Итак, какой у меня был бы вариант — нацелить ASP.NET Core 1.x на полноценную .NET?

Похоже, у меня есть ApiPort в будущем.

Итак, какой у меня был бы вариант — нацелить ASP.NET Core 1.x на полноценную .NET?

да.

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

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

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

.NET большой и старый, и вы не можете ожидать, что команда ASP.NET будет говорить с дыханием библиотек, существующих в экосистеме .NET. Это нереально. Я только что узнал, что такое CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) в рамках этой ветки, и я сомневаюсь, что он будет портирован, но я не могу сказать это для Конечно.

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

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

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

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

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

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

Разве это не хорошая причина продолжать поддерживать .NET 4.x? Бремя совместимости/взаимодействия может быть возложено на платформу .NET 4.x, которая может стать рабочим решением, которое избавит .NET Core от необходимости взаимодействовать со старыми библиотеками и ослабит необходимость переноса существующих популярных библиотек .NET на .NET Core ( для MS и внешних авторов).

@миф

Разве это не хорошая причина продолжать поддерживать .NET 4.x? Бремя совместимости/взаимодействия может быть возложено на платформу .NET 4.x, которая может стать рабочим решением, которое избавит .NET Core от необходимости взаимодействовать со старыми библиотеками и ослабит необходимость переноса существующих популярных библиотек .NET на .NET Core ( для MS и внешних авторов).

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

@gulbanana

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

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

Вот почему срок службы ASP.NET Core в версии 1.1 был увеличен (хотя и не навсегда).

Проблема в том, достаточно ли этого или нет, текущая версия в основном была EOL'ed еще до того, как был выпущен совместимый / стабильный выпуск.

Я не думаю, что стоимость существующих инвестиций рассматривается, кто захочет прилагать все усилия для перехода на платформу EOL? Разработчики будут работать над своими существующими заброшенными системами в течение неопределенного времени, им в основном говорят, что их текущие навыки ASP.NET v4.x устареют, и они не смогут перейти на новую модель разработки ASP.NET Core, потому что . NET 4.x прекращается, и с их стороны было бы безответственно рассматривать или рекомендовать переход на тупиковую платформу.

@davidfowl

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

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

Я так долго ждал asp.net core 2/ .net core 2, но результат такой депрессивный.

@миф

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

Нельзя ли сделать тот же аргумент о том, что ASP.NET Core 2.0 станет EOL для .NET Framework в следующем году, когда выйдет версия 3.0? Если вы говорите, что года недостаточно для ASP.NET Core 1.1, почему вы предлагаете год для ASP.NET Core 2.0?

Разработчики будут работать над своими существующими заброшенными системами в течение неопределенного времени, им в основном говорят, что их текущие навыки ASP.NET v4.x устареют, и они не смогут перейти на новую модель разработки ASP.NET Core, потому что . NET 4.x прекращается, и с их стороны было бы безответственно рассматривать или рекомендовать переход на тупиковую платформу.

Кому сказали, что навыки работы с ASP.NET 4.x устареют? Во всяком случае, мы надеемся, что это не так. MVC, в частности, рекламирует совместимость концепции с несколькими новыми функциями. ASP.NET Core очень похож на Katana (и это не случайно). Если вы говорите о веб-формах, то как насчет MVC?

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

@xyting можешь уточнить?

@davidfowl

Нельзя ли сделать тот же аргумент о том, что ASP.NET Core 2.0 станет EOL для .NET Framework в следующем году, когда выйдет версия 3.0? Если вы говорите, что года недостаточно для ASP.NET Core 1.1, почему вы предлагаете год для ASP.NET Core 2.0?

Я долгое время считал, что ASP.NET Core 1.1 — это просто временное решение для ASP.NET Core 2.0 и .NET Standard 2.0, которое будет ориентированным на совместимость и стабильным выпуском LTS, который устранит разрыв с большинством основные функции, отсутствующие в .NET 4.x - до тех пор, пока этот поток не разрушил это предположение. Сохранение совместимости с .NET 4.x вплоть до ASP.NET Core 2.0 не является идеальным решением, но это намного лучше, чем прекращать его в текущем выпуске, чего никто не ожидал.

Кому сказали, что навыки работы с ASP.NET 4.x устареют? Во всяком случае, мы надеемся, что это не так.

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

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

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

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

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

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

Хотя не нужно быть экстрасенсом, чтобы понять, что .NET Core — это платформа будущего .NET... если с самого начала (или, как вы выразились, «всегда») было намерение соединить ASP.NET Core с . NET core, это определенно не было передано ни в одном носителе, который я когда-либо видел.

Я буквально каждую минуту наблюдал за каждым стендапом ASP.NET (включая Хансельмана и Гленна, которые три часа устраняли неполадки в Docker... потому что у меня нет жизни), я читаю блоги, я всегда в Твиттере, я захожу в 2+ конференции в год, посещение групп пользователей и т. д., и я ни разу не слышал, чтобы это сообщалось как намерение ASP.NET Core. Вместо этого я снова и снова и снова слышу «это работает на обеих платформах», и, по праву, люди чувствуют, что кто-то вытащил стул из-под них. Я даже выступал с докладами об ASP.NET Core и сам говорил, что «он работает на обеих платформах», и теперь я чувствую себя виноватым перед всеми, кого повел по этому пути. Я бы сказал, что люди из ITT, вероятно, будут на переднем крае и будут наиболее восприимчивы к такого рода новостям, и здесь есть много негативной реакции. Похоже, что ситуация будет только ухудшаться, поскольку эта новость доходит до разработчиков и их менеджеров, которые не так вовлечены и, вероятно, более консервативны, чем те ITT.

Помимо отсутствия связи и поддержки некоторых сценариев, я думаю, что большая часть негативной реакции связана только со временем этого объявления. .NET Core 2 еще даже не вышел в RTM, и это уже считается единственным долгосрочным путем вперед, и, по сути, это была бомба замедленного действия, заложенная в Full Framework для ASP.NET Core. Я думаю, что многие наши страхи могли бы развеяться, если бы у нас было что-то материальное, с чем можно было бы играть помимо ночных сорочек.

Я действительно думаю, что должен быть лучший инструментарий, чем «запустить его и посмотреть, работает ли он» при ссылке на библиотеки net461+ из .NET Core 2+ в VS, потому что я уже вижу это сообщение «мы, вероятно, можем запустить большую часть ваши сборки 461+ тоже!" будет продаваться до смерти. Что-то, что могло бы анализировать отсутствующие API того, на что мы ссылались, предоставляя ошибки времени компиляции, в идеале даже предлагая совместимость nupkgs, если они существуют (например, System.Configuration в приведенном выше примере EF6... и чтобы это работало :smile:). Очевидно, что не все можно проанализировать во время компиляции (упомянутый выше сценарий распределенных транзакций приходит на ум как что-то сложное для анализа заранее), но чем больше это можно сделать, тем лучше. Что-то вроде того, что Immo сделал здесь для PlatformNotSupportedException и отсутствующих API-интерфейсов net461 для netstandard2 , было бы неплохо.

Просто мои 2 цента. Надеюсь, я просто слишком остро реагирую. В конце концов, многие из нас просто разочарованы, потому что мы любим ASP.NET Core и не хотим, чтобы что-то мешало нам его использовать. ❤️

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

Организация заказчика по-прежнему использует развертывание Windows 7, и этот проект является исключением, поскольку большинство их веб-проектов на самом деле выполняется в UNIX с Java, а .NET в основном используется в настольных приложениях.

Этот тип неопределенности просто накапливается в сломанной истории, которой были стек Windows 8 .NET и UWP, повышая интерес технического директора организации к поиску более стабильных альтернатив будущему .NET.

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

@davidfowl Возможно, это изменение подойдет для 99% проектов. Но он продавался как «работает на обеих платформах» и «при необходимости вы можете использовать его с полным фреймворком». Все знали, что полная версия ядра asp.net предназначена для проектов, которые нельзя было мигрировать, и это было нормально. И люди планировали с учетом этого.

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

@DamianEdwards @davidfowl Спасибо, что поделились планом.

SignalR на 1.x — это большое облегчение для замены нашей неподдерживаемой версии, а также новость о том, что ServiceBase будет следующей в списке, поскольку мы в настоящее время также используем ее!

Мы сильно зависим от EF6 и пространственных данных, поэтому мы застрянем на 1.x, пока у него не будет необходимого нам набора функций....

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

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

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

@shanselman @davidfowl Больше всего меня беспокоит NHibernate. Даже после выпуска EF Core он по-прежнему остается единственным наиболее совершенным полнофункциональным O/R-преобразователем.

@shanselman @DamianEdwards Я в процессе начинаю думать об обновлении сайта с ASP.NET MVC 4 до любой последней версии (я не понимаю, 5 это или одна). Мне все еще нужно запустить полную платформу .net, потому что я ссылаюсь на библиотеки SyncFusion и Telerik. SyncFusion для отображения файлов PDF и Telerik для создания файлов Word .docx. Как указывали другие, для стратегии Microsoft по этому поводу просто неразумно «попробовать и посмотреть, работает ли это». Я не могу гарантировать, что все будет работать, потому что это очень большая кодовая база стороннего кода.

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

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

Нехорошо для разработчиков и еще одна вещь, из-за которой разработчики теряют доверие к Microsoft (одна из многих за последние несколько лет). Мне кажется, что ASP.NET определенно должен работать на полном фреймворке .net, потому что существует такая большая библиотека инструментов, которые людям могут понадобиться для использования на их сервере. В моем случае я могу легко обновить до более поздней версии .net framework, если мне нужно, чтобы использовать последние материалы ASP.net, если для новой функциональности ASP.net требуется обновление.

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

...Стефан

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

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

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

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

Любой, кто будет следить за сообщениями в блоге на MSDN, будет знать, что 2.0 грядет, и они увидят в нем святой Грааль для преодоления разрыва между ядром asp.net и всем, что ему «отсутствовало» ранее, но они совершенно не подозревают об этом. что по сути является критическим изменением для определенных рабочих процессов. Было очень мало подробностей о том, что на самом деле происходит с дизайном asp.net core 2.0. Я подозреваю, что более подробная информация появится позже на этой неделе в Build? Можно только надеяться.

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

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

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

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

Одна из моих самых больших проблем с этим заключается в том, что почти на каждой конференции в прошлом году, когда был представлен ASP.NET Core, вы представляли его со слайдом, показывающим ядро ​​asp.net, работающее как на .net framework, так и на .net core, просто взгляните на это: Изучите веб-разработку с Microsoft ASP.NET Core 1.0 от Ignite в прошлом году. Примерно в 7.50 вы увидите горку.

Самыми важными для меня являются System.DirectoryServices, ServiceBase, EF6 (EF Core не готов), ClosedXML (для создания листов Excel).

Поддержка ASP.NET Core 1.x в .NET Framework будет продлена как минимум еще на год (до июля 2019 г.). Мы будем пересматривать это ежегодно и обязуемся предоставлять уведомление за 12 месяцев до прекращения поддержки ASP.NET Core 1.x (поэтому к июлю 2018 года мы объявим, продлеваем ли мы еще 12 месяцев до июля 2020 года) (Примечание: кого-нибудь еще напугал тот факт, что мы уже говорим о 2020 году? Нет? Хорошо, только я.)

@DamianEdwards Спасибо за объявление.

На данный момент наша компания разрабатывает корпоративные приложения для нескольких клиентов с использованием ASP.NET Core 1.1 на .NET Framework 4.6.2. Услышать, что поддержка этой комбинации фреймворков поддерживается как минимум до 2019 года и, возможно, продлена до 2020 года, — огромное облегчение.

В этом году мы перенесем System.DirectoryServices и System.Drawing на .NET Core (полная поддержка, кроссплатформенность, предварительная версия по крайней мере для Windows летом).

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

Похоже, что многие люди нарушили основное правило разработчика MS — не соглашайтесь ни на какой продукт/форк, по крайней мере, до версии V2.

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

Большинству людей, использующих ASP.NET, НЕ ВАЖНО, работает ли он на Linux. И если бы они увидели сообщение в блоге со сравнением скорости с ASPNET Core, они бы даже не стали читать прошлые кроссплатформенные версии, если бы увидели, что они не поддерживают устаревший .NET.

лолкоты.

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

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

Наличие двух версий ASP.NET Core (2.0 и 3.0) рядом действительно может быть полезным (по крайней мере, на какое-то время). Это может позволить MSFT быстрее отказаться от текущего стека MVC 5, потому что новая версия MVC, по сути, будет ASP.NET Core MVC 2.0, которая также будет работать на полной .NET.

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

Что может сделать его более плавным, чем перенос с ASP.NET Core 1.x?

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

Большая часть работы по обеспечению совместимости была выполнена в .NET Core 2.0 и .NET Standard 2.0. Честно говоря, в ASP.NET Core 2.0 не так много новых функций. Нам сказали, что мы собираемся перенести SignalR на ASP.NET Core 1.x (в любом случае это версия 2.0). Это просто восприятие?

Наличие двух версий ASP.NET Core (2.0 и 3.0) рядом может быть очень полезным.

Это то, что мы делаем с 1.1 и 2.0 (просто поменяйте местами числа).

Это может позволить MSFT быстрее отказаться от текущего стека MVC 5, потому что новая версия MVC, по сути, будет ASP.NET Core MVC 2.0, которая также будет работать на полной .NET.

MVC 5 никогда не исчезнет, ​​мы ничего не осуждаем. Он будет поддерживаться до тех пор, пока существует .NET Framework. Вы по-прежнему не можете запускать проекты ASP.NET Core внутри интегрированного конвейера IIS (в System.Web), и он не выполняет все те же функции, что и MVC 5 в System.Web, поэтому он действительно не заменяет определенные сценарии. .

@davidfowl Смогу ли я создать приложение ASP.NET Core 1.x, которое нацелено на полную версию .NET и netcoreapp2.0, чтобы я мог сначала перенести текущее устаревшее приложение на ASP.NET Core со всеми зависимостями net46x и постепенно мигрировать одна зависимость за другой для таргетинга на netstandard2.0, пока все не будет на netstandard2.0, что затем позволит мне обновить приложение ASP.NET Core 1.x до 2.x (и отбросить цель для net46x как часть этого)?

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

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

@alexwiese ах, хорошо, это здорово, тогда действительно, что мы сейчас здесь обсуждаем? Вместо того, чтобы обсуждать, на какую платформу ориентироваться, мы должны обсудить период поддержки ASP.NET Core 1.x, который MSFT может легко изменить, если захочет :)

РЕДАКТИРОВАТЬ:
@DamianEdwards написал это чуть выше в теме:

Поддержка ASP.NET Core 1.x в .NET Framework будет продлена как минимум еще на год (до июля 2019 г.). Мы будем пересматривать это ежегодно и обязуемся предоставлять уведомление за 12 месяцев до прекращения поддержки ASP.NET Core 1.x (поэтому к июлю 2018 года мы объявим, продлеваем ли мы еще 12 месяцев до июля 2020 года) (Примечание: кого-нибудь еще напугал тот факт, что мы уже говорим о 2020 году? Нет? Хорошо, только я.)

Звучит неплохо. Выделите еще один год поддержки, а затем периодически проводите повторную оценку. Имеет смысл для меня.

Я прочитал все сообщения в этой теме. Остается открытым один вопрос: почему принято такое решение? Я могу только заключить, что это было необходимо из-за технической проблемы. Если проблема заключается в «путанице» в названии, Microsoft следует нанять лучшего специалиста по связям с общественностью и прекратить раздувать дерьмо, как это делает команда в этой ветке.

Так в чем же заключается техническая проблема, которая заблокировала ASP.NET core 2.0 на netstandard2.0? В области программного обеспечения нет ничего невозможного, поэтому не может быть, чтобы вы не смогли придумать решение, которое невозможно реализовать в .NET full (и, следовательно, не может быть включено в netstandard20). Да, это требует времени и усилий, но у меня такое ощущение, что вы все на самом деле не осознали побочных эффектов этого решения для ваших пользователей, сколько времени и усилий им приходится вкладывать из-за этого.

У этого решения есть еще один недостаток: ASP.NET Core не является потребителем сетевого стандарта и, следовательно, не является его драйвером. Это делает сетевой стандарт последователем, а поскольку ядро ​​​​ASP.NET не зависит от него, последователем с небольшим значением: API .net core 2.0+ — это поверхность, на которую нужно ориентироваться, поскольку ядро ​​​​ASP.NET нацелено на эту поверхность, а не нетстандарт2.0.

И, извините, @davidfowl , я знаю, что вы имеете в виду хорошо, но предложение ASP.NET core 1.x людям снова и снова показывает, что вы действительно понятия не имеете, какова ситуация для людей, которым вы это предлагаете: люди не могут мигрировать к ASP.NET core 1.x, потому что они не знают, есть ли плавный путь без четкого дедлайна: возможно, им нужно оставаться на этой платформе дольше, чем они думают в настоящее время (зависимости должны быть перенесены так далее.). Уже одно это делает решение о переходе на ASP.NET core 1.x решение, основанное не на чем ином, как на «обещании» от Microsoft. Это API, предназначенный для кода, ориентированного на Интернет. Им нужно знать, смогут ли они запустить приложение, созданное сегодня, также в течение 3 лет, потому что Microsoft исправит в нем недостатки безопасности (для примера).

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

Microsoft продемонстрировала эту ветку и, извините, их ужасный пиар вокруг этой проблемы, они не могут дать такую ​​гарантию. И независимо от того, как много вы пытаетесь придать этому в ближайшие дни в \build, мы по другую сторону забора узнали, что Microsoft Marketing != гарантирует, что завтра все будет работать.

@FransBouma Я не думаю, что это была техническая проблема, похоже, мотивация ориентироваться только на netcoreapp2.0 заключается в том, что это единственный трек, который MSFT может двигаться так быстро, как им нравится, что хорошо для нас после все, потому что это означает, что ASP.NET Core 2.x может двигаться намного быстрее, чем любые другие веб-стеки в мире .NET раньше. Если вы не можете использовать этот скоростной поезд, вы можете дольше оставаться на ASP.NET Core 1.x (в настоящее время поддерживается до 2019 года).

@FransBouma , поскольку @davidfowl и @shanselman упомянули, что в .NET Core быстро добавляются новые API-интерфейсы, и ASP.NET Core 2.x будет использовать некоторые из них, поэтому желательно ориентироваться на netcoreapp20. Если бы они добавили эти API в netstandard2x, то .NET Framework и другим платформам пришлось бы наверстывать упущенное, а они, как известно, работают медленно.

Я собираюсь добавить свой голос на стороне дискуссии « Это хорошо» . Вот почему:

• Команда делает это не просто так. Существует множество новых функций и оптимизаций, готовых (или почти готовых) к внедрению в .NET Core, которые невероятно полезны для людей, создающих современные веб-приложения, API-интерфейсы и микросервисы и ожидающих появления этих функций в полной версии Windows .NET Framework. задержит выпуск на много месяцев.
• Многие жалобы, которые я вижу в этой ветке, представляют собой разновидность фразы «Я не могу сделать X в .NET Core 2.0», тогда как на самом деле автор имеет в виду _ «Я должен изменить способ, которым я делаю X в .NET Core 2.0». _. Да, вы должны измениться. Нет, это не плохо. Если у вас есть небольшая часть дискретной функциональности в вашем приложении ASP.NET MVC, которая делает что-то с файлами PDF или DOCX, и вы _действительно_ не можете найти лучший способ сделать то, что есть (вы пробовали?), тогда сломайте это функциональность в микрослужбу, работающую в полной версии .NET на Windows Server, и вызывать ее как HTTP API из приложения .NET Core. Декомпозиция приложений и перенос определенной функциональности в небольшие автономные службы — это даже не обходной путь, а _лучшая практика общего назначения_.
  
  
  
  • NB Насколько я могу судить, пакеты OpenXML теперь поддерживают .NET Standard, поэтому работа с Word/Excel/чем угодно не должна быть невозможной.
  
  
• .NET Core 2.0 еще даже не находится в надлежащем общедоступном предварительном просмотре, поэтому жаловаться на то, что он не поддерживает LDAP или что-то еще, кажется преждевременным. Если RTM появится в третьем квартале, а взаимодействия с AD, Kerberos или чем-то еще нет, то жалуйтесь (хотя также подумайте о переходе на современные системы аутентификации на основе токенов, потому что сейчас уже не 2008 год).
• Существует _гладкий_ переход с ASP.NET MVC 4.5 на ASP.NET Core 2.0. Он называется ASP.NET Core 1.0 (и я согласен с тем, что в данных обстоятельствах должно быть какое-то обещание долгосрочной поддержки 1.0). Вы можете создавать приложения, используя 1.0, и запускать их в полной версии .NET в интегрированном конвейере под IIS 8.5 в Windows Server 2012 R2 до тех пор, пока
  
  
  
  • Полный .NET догоняет, и вы можете запустить на нем ASP.NET Core 2.x, или
  
  
  • Любая сторонняя технология, от которой вы зависите, поддерживает .NET Core (или может быть заменена эквивалентной технологией, поддерживающей .NET Core).
  
  
• Помните, что хотя ваша команда может быть ограничена внешними зависимостями, внутренними политиками компании, политикой или просто инерцией, в мире есть сотни тысяч, если не миллионы разработчиков, которые хотят создавать приложения, службы и API с использованием современных технологий. архитектурные шаблоны и новые технологические платформы (облако/граничные устройства/IoT/и т. д.), которым отлично подходит ASP.NET Core 2.0. Они хотят, чтобы он был быстрым, масштабируемым и кроссплатформенным; эти вещи важны для многих людей. Глупо просить Microsoft игнорировать этот быстрорастущий рынок только потому, что ваш сторонний поставщик элементов управления или проект с открытым исходным кодом еще не перенесли свой код.

@dustinmoris предполагает, что в netstandard отсутствуют API-интерфейсы для создания быстрого веб-стека. Если это так, у всех нас есть большие проблемы.

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

Дело не в том, что основная команда asp.net не должна двигаться быстро, а в том, что они делают это так, что это противоречит предположениям многих людей, когда они переходили на asp.net core 1.x.

@FransBouma Как вы думаете, почему у вас есть лучшее представление о том, что пользователи Microsoft делают с продуктами Microsoft, чем у Microsoft?

@маркрендл

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

Итак, скажите мне, почему бы не создать эти супер-пупер-API в виде пакетов стандарта .net 2.0 и не опубликовать их на nuget?

Как вы думаете, почему у вас есть лучшее представление о том, что пользователи Microsoft делают с продуктами Microsoft, чем у Microsoft?

О, я не знаю, читая сообщения в этой теме?

@ФрансБума

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

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

Итак, вопрос в том, хочет ли ASP.NET Core 2.x зафиксировать netstandard2.0 (на данный момент самый высокий), а затем знать, что он застрял со всем, что было определено там, или только ASP.NET Core 2.x зафиксируйте на netcoreapp2.x, что может быть намного больше, чем просто netstandard2.0. Через некоторое время я уверен, что снова появится более новый сетевой стандарт (3.x?), который догонит новые блестящие вещи от netcoreapp, но это займет гораздо больше времени, и почему ВСЕ фреймворки asp.net должны быть искалечены для медленного прогресса. . Приятно иметь один действительно быстро развивающийся стек ASP.NET Core, пока есть второй, который дает людям более долгосрочную поддержку, соответствующую netstandard.

@FransBouma О, извините, я не знал, что размер вашей выборки такой большой. 257 комментариев с сильным уклоном в сторону людей, которым решение не нравится? Трудно с этим поспорить.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я не эксперт по большим данным.

@davidfowl :

На протяжении всей этой темы вы называли System.DirectoryServices одной из основных вещей. Я предполагаю, что у вас есть некоторые зависимости, перенос которых, по вашему мнению, займет много времени, или такие, которые никогда не будут перенесены. Если бы 2.0 поддерживал .NET Framework, эти зависимости переместились бы через год?

Да, у нас есть другие вещи. Службы System.Directory — это то, на что я указываю, потому что даже самое запрашиваемое пространство имен не готово. Всем остальным хуже. Анализатор переносимости API даже не обновлен для VS 2017, где мы можем его запустить. Анализатор, чтобы увидеть, можете ли вы даже портировать , не был вложен, и мы уже отказываемся от поддержки.

Какие?

Razor pages — это огромная тема, я упоминал ее несколько раз.

Я ничего не знаю о stackoverflow.com, но можно ли отломать части (я не хочу говорить «микросервисы»), чтобы можно было использовать ASP.NET Core для некоторых частей?

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

Я думал, что объяснил это ранее, но вот еще раз:

Любой API, являющийся частью сетевого стандарта, который нуждается в развитии, будет развиваться медленно. Вещи могут быть построены поверх сетевого стандарта и могут работать где угодно, и это нормально. В тот момент, когда вам нужен новый API, скажем, для http-клиента, или SSL-потока, или Int, или String, или Array, или LINQ, или любого из примитивов, существующих в NET Standard, необходимо создать новую версию .NET Standard и реализовать договориться о том, что они его реализуют. Теперь это не конец света, потому что теперь мы владеем большинством из них: mono, .NET Core, .NET Framework, UWP, но есть и другие, такие как Unity (и, возможно, другие). У каждой вертикали .NET есть свои временные рамки и цикл поставки, каждый из них является отдельным продуктом, и это нельзя игнорировать.

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

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

@DamianEdwards и @shanselman А как насчет Service Fabric и модульных тестов?

В нашем случае у нас есть большой проект микросервиса с множеством приложений SF, которые являются основными проектами, но используют .Net Framework 4.5 до 4.6 (что-то). В настоящее время SF не поддерживает netcoreapp, поэтому нам пришлось использовать .Net Framework, но, поскольку мы не хотели отставать, мы использовали проект .Net Core.

(другая проблема заключается в том, что) Поскольку наши услуги представляют собой .Net Framework, а MS Fakes недоступны для netcoreapp, все наши модульные тесты являются обычными (или, я должен сказать, устаревшими) проектами .Net Framework. Почти все наши библиотеки находятся на сетевом стандарте от 1.0 до 1.6.

Опять же, наши клиентские приложения используют Xamarin Forms + UWP, и нам удалось использовать netstandard, поэтому наши библиотеки совместимы.

Означает ли это, что мы застряли и не сможем перейти на .Net Core 2.0, netcoreapp2.0 и netstandard 2.0?

@НикКравер

Razor pages — это огромная тема, я упоминал ее несколько раз.

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

Да, у нас есть другие вещи. Службы System.Directory — это то, на что я указываю, потому что даже самое запрашиваемое пространство имен не готово. Всем остальным хуже. Анализатор переносимости API даже не обновлен для VS 2017, где мы можем его запустить. Анализатор, чтобы увидеть, можете ли вы даже портировать, не был вложен, и мы уже отказываемся от поддержки.

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

@абу

Означает ли это, что мы застряли и не сможем перейти на .Net Core 2.0, netcoreapp2.0 и netstandard 2.0?

Вы имели в виду ASP.NET Core 2.0 и? .NET Core 2.0 и .NET Standard 2.0 здесь не подходят.

Да, вам придется остаться на ASP.NET Core 1.x.

Большая часть работы по обеспечению совместимости была выполнена в .NET Core 2.0 и .NET Standard 2.0. Честно говоря, в ASP.NET Core 2.0 не так много новых функций. Нам сказали, что мы собираемся перенести SignalR на ASP.NET Core 1.x (в любом случае это версия 2.0). Это просто восприятие?

@davidfowl Я думаю, вы сильно недооцениваете страх, который поражает сердце разработчика Windows, когда вам говорят, что вам придется перенести что-то. _Особенно_ когда новый стек не достиг паритета функций со старым стеком, и неизвестно, произойдет ли это и когда. По сути, это объявление об окончании срока службы ASP.NET Core в полной версии .NET Framework. И хотя это, вероятно, не было долгосрочным планом, это было объявлено как функция, и люди думали, что она может остаться на некоторое время. Дорожные карты меняются, пока мы говорим. Встречи будут.

У нас есть некоторые отвратительно старые вещи, которые мы должны поддерживать из-за номинально поддерживаемых коннекторов баз данных и SDK. Некоторые из этих поставщиков с гораздо большей вероятностью выпустят новый, урезанный API с 30% существующей функциональностью, интерфейсом HTML5 и новым набором ошибок, чем будут поддерживать свои существующие продукты. Или они могут просто нанять конкурента, выпустить продукт и быстро завершить его работу. Некоторые из этих поставщиков достаточно велики, чтобы быть узнаваемыми. У нас есть много хорошего кода, но часть этого кода также живет в трущобах Windows, несмотря на все наши усилия, потому что он не всегда находится под нашим контролем. Старые технологии не просто так изящно уходят на пенсию. Он прячется под вашей кроватью, в нашем шкафу и под вашей клавиатурой.

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

Другим разработчикам приходится добавлять в код директивы компилятора, разбивать код на библиотеки для конкретных платформ и компилировать с несколькими целями. Грубая часть меня хочет, чтобы команда ASP.NET Core провела тестовую проверку, чтобы вы были заинтересованы в лучшей среде выполнения и поддержке инструментов для многоцелевых и многоплатформенных сценариев. И если ваша команда хочет этого, мы можем это получить. Практическая часть меня говорит, что как минимум у вас должны быть периодические выпуски ASP.NET Core, ориентированные на .NET Standard. Вам в любом случае нужно делать настоящие _стабильные_ релизы. Никто не собирается просто скомпилировать основную ветку из git и развернуть ее в рабочей среде. Почему бы не сделать меньшие версии .NET Standard и не сопоставить их с выпуском ASP.NET с тегами?

Кроме того, будет ли новый ASP.NET для рабочего стола? Из-за всей этой шумихи казалось, что ASP.NET Core — единственная ASP.NET. Похоже, вы не получите ничего нового в ASP.NET, если не используете .NET Core. И это изменит многие бизнес-стратегии. С дорожными картами происходит много путаницы.

MVC 5 никогда не исчезнет, ​​мы ничего не осуждаем. Он будет поддерживаться до тех пор, пока существует .NET Framework.

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

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

@davidfowl я думаю. Что вы называете основным проектом (новым) с .Net Framework? Что бы это ни было, насколько я понял из поста, netstandard vNext не будет поддерживать это.

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

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

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

Многие жалобы, которые я вижу в этой ветке, представляют собой разновидность фразы «Я не могу сделать X в .NET Core 2.0», тогда как на самом деле автор имеет в виду «Я должен изменить способ, которым я делаю X в .NET Core 2.0». Да, вы должны измениться. Нет, это не плохо. Если у вас есть небольшая часть дискретной функциональности в вашем приложении ASP.NET MVC, которая делает что-то с файлами PDF или DOCX, и вы действительно не можете найти лучший способ сделать то, что есть (вы пробовали?), тогда сломайте это функциональность в микрослужбу, работающую в полной версии .NET на Windows Server, и вызывать ее как HTTP API из приложения .NET Core. Декомпозиция приложений и перемещение определенных функций в небольшие автономные службы — это даже не обходной путь, а универсальная передовая практика.

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

.NET Core 2.0 еще даже не находится в надлежащем общедоступном предварительном просмотре, поэтому жаловаться на то, что он не поддерживает LDAP или что-то еще, кажется преждевременным. Если RTM появится в третьем квартале, а взаимодействия с AD, Kerberos или чем-то еще нет, то жалуйтесь (хотя также подумайте о переходе на современные системы аутентификации на основе токенов, потому что сейчас уже не 2008 год).

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

Существует плавный переход с ASP.NET MVC 4.5 на ASP.NET Core 2.0. Он называется ASP.NET Core 1.0 (и я согласен с тем, что в данных обстоятельствах должно быть какое-то обещание долгосрочной поддержки 1.0).

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

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

Он нацелен на netcoreapp , этого не произойдет.

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

Эти библиотеки часто находятся вне контроля людей и времени. Даже библиотеки от Microsoft не обновляются . Я борюсь с командой SQL прямо сейчас, чтобы обновить их пакеты для работы в новой системе проектов, потому что install.ps1 работает. Если мы даже не можем установить эти простые исправления, мы облажались с портами на netstandard .

Помните, что хотя ваша команда может быть ограничена внешними зависимостями, внутренними политиками компании, политикой или просто инерцией, в мире есть сотни тысяч, если не миллионы разработчиков, которые хотят создавать приложения, службы и API с использованием современных технологий. архитектурные шаблоны и новые технологические платформы (облако/граничные устройства/IoT/и т. д.), которым отлично подходит ASP.NET Core 2.0. Они хотят, чтобы он был быстрым, масштабируемым и кроссплатформенным; эти вещи важны для многих людей. Глупо просить Microsoft игнорировать этот быстрорастущий рынок только потому, что ваш сторонний поставщик элементов управления или проект с открытым исходным кодом еще не перенесли свой код.

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

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

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

Я наблюдал за .NET Core, участвовал и конвертировал небольшие проекты с .NET Framework на .NET Standard / .NET Core, чтобы получить некоторый опыт работы с новым SDK и средой выполнения, а также запускать эти проекты на macOS и Linux. .

Моя большая цель — крупный корпоративный веб-сервис, использующий кучу компонентов, недоступных [пока] в .NET Core 1.0 или 1.1. Это включает в себя, как раз из макушки моей головы:

• Active Directory ( System.DirectoryServices ), используемый для аутентификации и управления пользователями.
• Entity Framework 6 ( EntityFramework ), поскольку EF Core еще не поддерживает многие функции, которые мы используем.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, клиентская библиотека Javascript, которую мы используем, не поддерживает v4 (пока), а WebAPI OData намного сложнее настроить.
• IIS Management ( System.Web.Management ) и .NET Remoting ( System.Runtime.Remoting ) для возможности обновления веб-службы, хотя это может быть извлечено в отдельное приложение.
• СигналR
• Пользовательские IHttpHandler s и IHttpModule s, которые должны быть адаптированы к любому эквиваленту ASP.NET Core, возможно, к какому-то промежуточному программному обеспечению.
• Целая куча пользовательских вещей, использующих расширяемость ASP.NET WebAPI.
• Я думаю, что мы могли бы даже использовать Microsoft.TeamFoundationServer.ExtendedClient на сервере, который поддерживает только net46, имеет несколько собственных сборок и имеет около 0% шансов на работу с .NET Core 2.0.
• и т.п.

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

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

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

@davidfowl

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

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

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

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

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

Для справки: OData — это еще одна библиотека, которая еще не поддерживает netcoreapp.

На самом деле он даже все еще основан на System.Web (вы должны использовать его через промежуточное ПО OWIN в ASP.NET Core), и они обещали поддержку (см. https://github.com/OData/WebApi/issues/939).

Еще стоит упомянуть. Тем более, что это от Microsoft.

РЕДАКТИРОВАТЬ: @yaakov-h был на 2 минуты быстрее, так что +1 за упоминание OData

Я все еще здесь отвечаю по нескольким причинам

• мне не все равно
• Сон для слабаков 😆
• Мне нужно вызвать FUD, потому что кто-то в Интернете неправ.

@НикКравер

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

Это просто означает, что вы не можете использовать страницы Razor. Tbh, ASP.NET Core 2.0 имеет много мелких вещей, но нет больших функций или исправлений, которые также не переносятся обратно в 1.x. EOL вполне реален, и лично я не думаю, что ASP.NET Core 2.0, поддерживающий .NET Framework еще год, поможет. На самом деле мы обсуждаем здесь смену направления, либо мы навсегда поддерживаем .NET Framework, либо нет, промежуточного варианта действительно нет.

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

Я разрабатываю приложения aspnetcore 1. * и использую рабочий стол .NET в качестве среды выполнения (LOB для предприятий).

И я понимаю, в чем разница между средой выполнения .net core, netstandard и т. Д. (Просто чтобы убедиться, что это не комментарий о неправильном понимании этого)

Сначала я перешел на ядро ​​​​aspnet (нацеливаясь на рабочий стол .net), потому что поток / видение / и т. Д., Консолидация его и ПОСЛЕ перемещения на ядро ​​​​.net (если возможно) были решающим сценарием в выборе aspnetcore.

Эта проблема немного неожиданна, потому что aspnetcore 1. * всегда продавался как «работающий на обеих платформах» с нулевыми предупреждениями о том, что он будет удален в следующем (версия или год).
Я ожидал, по крайней мере, устаревшего -> устаревшего цикла или просто неподдерживаемых функций (это нормально).

Хорошая часть .net (и aspnet в качестве выбора для веб-стека) заключается в том, что я могу использовать существующую кодовую базу и библиотеки.
Некоторые из них являются внутренними, и нет реальной рентабельности их миграции, когда цель (.net core/netstandard) слишком изменчива.
Некоторые из них являются внешними, и их трудно изменить, если они не работают в закрытии netcoreapp2, я не могу их использовать.

Кроме того, моя идея заключалась в том, чтобы объединить netstandard2 , а не netcoreapp2 .
Как я могу начать просто оценивать перенос библиотек на netstandard2, если его еще нет? Трудно оценить миграцию на основе предварительных битов и обещаний (и последние годы снизили мое доверие к стабильности обещаний).

Я понимаю, что это другой сценарий, чем полностью с нуля, но также, если с нуля я хотел бы повторно использовать некоторые библиотеки, потому что мне нужно взаимодействовать с существующей системой (excel/pdf/и т. д.), а не переписывать все с нуля.
Или добавьте микросервисы как rpc только потому, что это последняя тенденция, потому что все усложняется (это осознанный выбор, который я хочу оценить и сделать, а не заставлять обертывать существующие библиотеки). Мне нужно приносить пользу (поток разработки aspnetcore приятный и продуктивный), а не просто менять архитектуру.

По моей личной оценке экосистемы, для моего варианта использования доступность .net core и/или netstandard lib слишком низкая (не все используют только бесплатные пакеты nuget.org oss). Поэтому, если мне нужно жестко перейти на новый стек, мне нужно оценить и другие стеки (стоимость/выгода/будущее/доверие/и т. д.)

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

Плавная миграция требует времени, мне нравится видение будущего ядра aspnet. но если у меня нет четкого пути (или я сомневаюсь в этом), трудно продать внутри.

Тем не менее, оставьте рабочий стол .net позади, это может быть хорошей игрой команды aspnet, чтобы двигаться быстрее и выбирать больше новых пользователей (или не терять потоки на node/java).
Но наверняка это усложнит жизнь разработчикам на более медленном кольце, и это вызов команды aspnet (их продукт).
Мой отзыв заключается в том, чтобы не делать этого и усердно работать над поддержкой fw, потому что как разработчику мне нужны доверие и стабильность, и в последние годы, когда экосистема .net была слишком подвижной (не только netcore/project.json, но и до да и маркетинг/евангелист не помог снизить доверие)

@yaakov-h

Если вы решите перенести на ASP.NET Core (1.x или 2.x), вам понадобится другой процесс. ASP.NET Core не работает в System.Web, поэтому вы не можете выполнять постепенный перенос в том же проекте.

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

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

@davidfowl , который полностью зависит от наших исходных зависимостей. На данный момент мы навсегда останемся на .NET Framework.

Интересно, что у большинства сторонних уже есть выпуски netstandard . В основном это зависимости от Microsoft, которые удерживают нас на .NET Framework, и некоторые из них кажутся полузаброшенными (например, OData).

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

Посмотрите на это так: если бы вы начали с нуля создание следующего Stack Exchange (каким бы он ни был) сегодня, разве не было бы то, что находится в netcoreapp20 , которое хочет использовать команда ASP.NET Core ( такие как UTF8Strings и Pipelines, а также асинхронные, _fast_ примитивы с малым выделением памяти (мне кажется), делают его более привлекательным для вас, чем полноценный .NET? Разве .NET Core 2.0 в целом не имеет больше смысла, чем полноценная .NET 4.7.1? Если бы вы выбирали между веб-стеками, которые могут быстро развиваться и адаптироваться к изменениям, и веб-стеками, которые необратимо привязаны к медленно развивающейся базовой технологии с почти двумя десятилетиями устаревшего кода, о поддержке которого нужно беспокоиться, что бы вы выбрали?

@ZigMeowNyan

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

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

Другим разработчикам приходится добавлять в код директивы компилятора, разбивать код на библиотеки для конкретных платформ и компилировать с несколькими целями. Грубая часть меня хочет, чтобы команда ASP.NET Core провела тестовую проверку, чтобы вы были заинтересованы в лучшей среде выполнения и поддержке инструментов для многоцелевых и многоплатформенных сценариев. И если ваша команда хочет этого, мы можем это получить. Практическая часть меня говорит, что как минимум у вас должны быть периодические выпуски ASP.NET Core, ориентированные на .NET Standard. Вам в любом случае нужно делать настоящие стабильные релизы. Никто не собирается просто скомпилировать основную ветку из git и развернуть ее в рабочей среде. Почему бы не сделать меньшие версии .NET Standard и не сопоставить их с выпуском ASP.NET с тегами?

Мы делаем то же самое, помните, что мы по-прежнему ориентируемся на netstandard для множества наших библиотек, и они содержат ifdef. Другие, однако, нацелены на netstandard, чтобы настроить нас на использование преимуществ новых API во временных рамках 2.x.

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

Честный вопрос (это я спрашиваю, а не Microsoft): вы предпочитаете совместимость новым функциям? Если да, то почему стоит выбрать ASP.NET Core?

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

Интересно, что у большинства сторонних производителей уже есть выпуски netstandard. В основном это зависимости от Microsoft, которые удерживают нас на .NET Framework, и некоторые из них кажутся полузаброшенными (например, OData).

😞

@маркрендл

• Многие жалобы, которые я вижу в этой ветке, являются разновидностью фразы «Я не могу сделать X в .NET Core 2.0», тогда как на самом деле автор имеет в виду «Я должен изменить способ, которым я делаю X в .NET Core 2.0». . Да, вы должны измениться. Нет, это не плохо. Если у вас есть небольшая часть дискретной функциональности в вашем приложении ASP.NET MVC, которая делает что-то с файлами PDF или DOCX, и вы действительно не можете найти лучший способ сделать то, что есть (вы пробовали?), тогда сломайте это функциональность в микрослужбу, работающую в полной версии .NET на Windows Server, и вызывать ее как HTTP API из приложения .NET Core. Декомпозиция приложений и перемещение определенных функций в небольшие автономные службы — это даже не обходной путь, а универсальная передовая практика.
NB Насколько я могу судить, пакеты OpenXML теперь поддерживают .NET Standard, поэтому работа с Word/Excel/чем угодно не должна быть невозможной.<<

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

Я могу заверить вас, что потратил много времени на изучение лучших инструментов, которые мы можем использовать для создания PDF и DocX, и это далеко не так просто, как с открытым XML. Мы используем стороннюю библиотеку, потому что они разработали десятки тысяч строк кода, и нам не нужно разрабатывать/поддерживать/тестировать. В этом весь смысл.

Управление версиями .net стало очень сложным. Мне не ясно, можно ли когда-нибудь в будущем использовать ASP.net на полной платформе .net? Поскольку мне нужно совместно использовать код между сервером и моими настольными приложениями, значит ли это, что у меня никогда не будет последней версии ASP.Net? Это не проблема в краткосрочной перспективе, но в долгосрочной перспективе с улучшениями безопасности и так далее я не хочу быть слишком далеко от последней версии. Я уверен, что в моей лодке есть много других, где вам нужна какая-то форма совместимости с полной структурой.

Чтобы пояснить, что я делаю, у меня есть три собственные библиотеки, которые совместно используются различными приложениями WPF и моим сервером. На данный момент я понятия не имею, какой API, который я использую, может быть или не быть доступным в ядре .net. А затем в этих библиотеках я использую полные настольные версии инструментов WPF Telerik и SyncFusion для создания docx и pdf. Некоторые или все функции, используемые этими инструментами, могут быть доступны или недоступны в ядре .net. Пытаться разрабатывать приложения на основе принципа «может быть может, а может и нет» чрезвычайно сложно. У Microsoft есть блестящая базовая структура в .net, и хотя я понимаю причины, лежащие в основе .net core. Похоже, Microsoft забыла о важности обратной совместимости.

Стефан

@маркрендл

Ой, извините, я не знал, что у вас такой большой размер выборки. 257 комментариев с сильным уклоном в сторону людей, которым решение не нравится? Трудно с этим поспорить. ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: я не эксперт по большим данным.

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

@стефанолсон

Версионирование .net стало очень сложным

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

Мы планируем портировать на .Net Core x.
Наши самые большие проблемы связаны с:
NewRelic (нет плана .Net Core, поэтому нам нужно найти альтернативу)
NH (где EF Core не имеет функций).
ServiceBase (похоже, летом он выйдет на .Net Core 2)

Конечно , похоже , что нам придется нацелиться на Core 1.0 в промежутке и ждать обновлений NH, EF или проявить творческий подход.

Это просто означает, что вы не можете использовать страницы Razor. Tbh, ASP.NET Core 2.0 имеет много мелких вещей, но нет больших функций или исправлений, которые также не переносятся обратно в 1.x. EOL вполне реален, и лично я не думаю, что ASP.NET Core 2.0, поддерживающий .NET Framework еще год, поможет. На самом деле мы обсуждаем здесь смену направления, либо мы навсегда поддерживаем .NET Framework, либо нет, промежуточного варианта действительно нет.

Он немного больше, чем страницы Razor, а значит , нет причин его перемещать . Просто не существует (текущего) сценария, в котором существуют оба из них:

1. Мы будем поддерживать все время
2. На другой стороне есть фактическое обновление

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

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

Я думаю, что ASP.NET Core великолепен. Вы, ребята, делаете потрясающие вещи. Мне посчастливилось помочь с некоторыми из них. Но этот переключатель в данный момент времени плохой. Если все вещи, которые, как мы думаем, будут перенесены, на самом деле перенесены во временные рамки 2.x, тогда отлично. Тогда внесите изменения в 3.x. Портирование до того, как альтернатива будет готова, и установка крайнего срока, когда можно убить линию жизни EOL, — это плохо. Говорить людям о переносе на версию обслуживания -> EOL — это плохо.

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

@FransBouma Вы (должны) прекрасно знать, что у Microsoft есть обширные базы данных телеметрии, отзывов и других данных о том, что люди делают со своими технологиями, которые дают гораздо более четкую картину, чем любое количество тем GitHub Issues, и я не думаю, что мой указание на это было куда более язвительным, чем

О, я не знаю, читая сообщения в этой теме?

Управление версиями .net стало очень сложным. Мне не ясно, можно ли когда-нибудь в будущем использовать ASP.net на полной платформе .net? Поскольку мне нужно совместно использовать код между сервером и моими настольными приложениями, значит ли это, что у меня никогда не будет последней версии ASP.Net? Это не проблема в краткосрочной перспективе, но в долгосрочной перспективе с улучшениями безопасности и так далее я не хочу быть слишком далеко от последней версии. Я уверен, что в моей лодке есть много других, где вам нужна какая-то форма совместимости с полной структурой.

История совместного использования кода в разных средах выполнения .NET — это .NET Standard. Ваши библиотеки должны попытаться нацелить это на код, совместно используемый в .NET Core и .NET Framework.

Похоже, Microsoft забыла о важности обратной совместимости.

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

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

@НикКравер

Он немного больше, чем страницы Razor, а значит, нет причин переезжать. Просто не существует (текущего) сценария, в котором существуют оба из них:

Можете ли вы уточнить?

Дело в том, что ASP.NET Core не так уж полезен без экосистемы. Наличие контроллера, который отображает текст обратно, — это здорово, но бесполезно для такого количества сценариев.

Это тоже можно сделать очень быстро 😉

Я думаю, что ASP.NET Core великолепен. Вы, ребята, делаете потрясающие вещи. Мне посчастливилось помочь с некоторыми из них. Но этот переключатель в данный момент времени плохой. Если все вещи, которые, как мы думаем, будут перенесены, на самом деле перенесены во временные рамки 2.x, тогда отлично. Тогда внесите изменения в 3.x. Портирование до того, как альтернатива будет готова, и установка крайнего срока, когда можно убить линию жизни EOL, — это плохо. Говорить людям о переносе на версию обслуживания -> EOL — это плохо.

Я не понимаю, почему 2.x (поддержка) и 3.x (дроп) лучше, чем 1.x (поддержка) и 2.x (дроп). Не могли бы вы объяснить это мне? Какая разница?

Несколько рекомендаций сеанса //BUILD 2017 для тех, кто обеспокоен долгосрочной поддержкой вариантов ASP.NET:

• Обновления веб-форм T6009 ASP.NET
  
  
  
  • т.е. они все еще разрабатывают полные веб-платформы .NET
  
  
• Поддержка T6072 для ASP.NET Core: что такое LTS?
  
  
  
  • Который, как я полагаю, сейчас лихорадочно обновляется :grimacing:
  
  

@davidfowl :

Какая разница?

Потому что вы пообещали, что некоторые из наиболее значительных отсутствующих API появятся после версии 2.0?

@yaakov-h

Потому что вы пообещали, что некоторые из наиболее значительных отсутствующих API появятся после версии 2.0?

Подскажите какие в ASP.NET Core?

@davidfowl System.DirectoryServices, System.Drawing упоминались выше.

Честный вопрос (это я спрашиваю, а не Microsoft): вы предпочитаете стабильность и совместимость новым функциям? Если да, то почему стоит выбрать ASP.NET Core?

Я думаю, что это очень хороший вопрос. Если полная платформа .NET дает все, что нужно сегодня, почему так хочется перейти на совершенно другой стек? Если бы .NET Core и ASP.NET Core назывались по-разному, без .NET в названии, то, я думаю, гораздо меньше людей спорили бы о проблемах миграции. Никто не жалуется, что не может перейти на более быстрый веб-стек Go или Node.js.

Обратная совместимость @davidfowl с ASP.NET MVC 5.x — это одно, а обратная совместимость с .net framework — это другое. Отказ от .net framework - это большое дело...

Я не понимаю, почему 2.x (поддержка) и 3.x (дроп) лучше, чем 1.x (поддержка) и 2.x (дроп).

Потому что 2.x появится очень скоро, как мы понимаем.

@davidfowl System.DirectoryServices, System.Drawing упоминались выше.

Они не имеют ничего общего с ASP.NET Core 1.x или 2.x и будут работать на обоих, когда они появятся в сети.

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

@FransBouma Вы (должны) прекрасно знать, что у Microsoft есть обширные базы данных телеметрии, отзывов и других данных о том, что люди делают со своими технологиями, которые дают гораздо более четкую картину, чем любое количество тем GitHub Issues, и я не думаю, что мой указание на это было куда более язвительным, чем

Телеметрия @markrendle — это не волшебство. Вы не можете измерить, почему ppl/dev не переключаются, или почему они переключились на другой стек, или важность их проекта, и насколько им нравится этот стек (и они помогают другим, консультируя или oss), или то, что они делают.

Эта тема именно такая, обратная связь.

Я не понимаю, почему 2.x (поддержка) и 3.x (дроп) лучше, чем 1.x (поддержка) и 2.x (дроп). Не могли бы вы объяснить это мне? Какая разница?

@davidfowl время.
пора немного успокоиться. время оценивать вещи. пора менять одну вещь за раз. пора использовать пакеты netstandard2 с rtm. пора переместить наши библиотеки на netstandard2 (проще) вместо netstandard1 (сложнее). Пора менять что-то одно за раз, в основном для меня.
Вы делаете aspnet, но мой продукт — это не только aspnet, это комбинация множества библиотек, компромиссов и экосистемы.

Потому что 2.x появится очень скоро, как мы понимаем.

Какое это имеет отношение к этому? Что, если 2.0 выйдет в конце года или в январе? Будет ли это иметь значение? Что такого в 2.0, что делает 1.x недостойным?

@yaakov-h Они были упомянуты здесь, где сказал @shanselman (выделено мной)

AD. В общем, это пробел, ЕСЛИ вы хотите вызывать LDAP напрямую. Вы, безусловно, можете авторизоваться с Windows Auth СЕЙЧАС. Мы планируем создать специальное пространство имен DirectoryServices для Core 2.0 в летнее время.
Рисунок – В общем, это пробел. Мы планируем сделать это для Core 2.0 примерно летом . До этого эти параметры сетевого стандарта также существуют для параметров ImageSharp, ImageResizer, Mono и т. д.

@davidfowl речь идет не о версии, а о дате и зрелости ядра .net и его экосистемы.

@hikalkan

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

@энрикосада

пора немного успокоиться. время оценивать вещи. пора менять одну вещь за раз. пора использовать пакеты netstandard2 с rtm. пора переместить наши библиотеки на netstandard2 (проще) вместо netstandard1 (сложнее). Пора менять что-то одно за раз, в основном для меня.
Вы делаете aspnet, но мой продукт — это не только aspnet, это комбинация множества библиотек, компромиссов и экосистемы.

Почему это имеет значение конкретно для ASP.NET Core 2.0? Вы получите это преимущество от платформы независимо от того, что ASP.NET Core решит делать.

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

@enricosada Вы можете получить очень много полезной информации из телеметрии и других источников данных (веб-аналитика, данные поиска, прямая обратная связь с клиентами). Гораздо больше, чем вы можете получить от разгневанной толпы на GitHub (каким бы оправданным ни был гнев каждого человека).

@ yaakov-h Что ж, текущий прогнозируемый RTM для .NET Core 2.0 (и, следовательно, ASP.NET Core 2.0) — это календарный Q3, то есть июль/август/сентябрь), а лето в северном полушарии в основном июль/август/сентябрь. , так что это в основном одно и то же.

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

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

Я не понимаю, почему 2.x (поддержка) и 3.x (дроп) лучше, чем 1.x (поддержка) и 2.x (дроп). Не могли бы вы объяснить это мне? Какая разница?

@davidfowl Время. И правильный анонс. Если бы сообщение было более четким, люди не были бы так удивлены.

@davidfowl Время. И правильный анонс. Если бы сообщение было более четким, люди не были бы так удивлены.

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

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

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

Итак, давайте предположим, что netcore не существует, а ядро ​​aspnet основано на netstandard. это означает, что функции будут появляться медленнее.

Пример:
2017 asp.net хочет функцию A.
Netstandard 2018 реализует Feature A. Мы получаем Feature A на ns.

Команда говорит, что сетевое ядро ​​не должно быть основано на сетевом стандарте, поэтому:
2017 asp.net хочет функцию A
Команда aspnet 2017 реализует функцию A. Asp.Net Core получает функцию A на netcore.
2018 netstandard реализует функцию A. мы получаем функцию A на ns.

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

Если сетевое ядро, основанное на сетевом стандарте 2, означает, что функции будут выпущены на 1 год (или любой другой период времени) позже, люди все равно будут утверждать, что они этого хотят? Это сценарий, к которому мы привыкли с NET Framework .

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

Авторы библиотек должны по-прежнему ориентироваться на сетевой стандарт, и если вы можете, то не беспокойтесь.
Если вам нужно что-то, не относящееся к netstandard (может быть, Razor Pages (?)), то вы должны ориентироваться на netcore, в сценарии 1 Razor Pages может даже не существовать. Я не понимаю, как это может быть плохо, я бы сказал, что это справедливо.

Итак, вопрос в том, какая зависимость у вас есть прямо сейчас, которая ограничивает вас от перехода с NET Framework на Net Core?
Я могу быть единственным здесь, но я никогда не ожидал, что ядро ​​​​aspnet будет работать на NET Framework вечно, для меня было очевидно, что это был «переходный» шаг. Все мои разработки, которые в настоящее время нуждаются в NET Framework, это splited . (и нет, это не микросервисы, это намного проще).

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

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

@davidfowl Я думаю, что в текущем предложении может быть тонкая скрытая проблема, которая беспокоит разработчиков.
Если у вас есть функция A для asp.net (с сетевым ядром), вы можете продавать и отправлять (и отмечать флажок management/pm) и быть «ленивым» для реализации на netstandard, если я не ошибаюсь, это то, что «ставка» о неуверенности упоминается здесь.
Итак, в моем предыдущем примере netstandard реализует функцию A в 2019, 2020 или никогда вместо 2018 года. <-- это выглядит как возможная проблема (?), я прав? Может ли Microsoft взять на себя что-то здесь?

Хотя мы все можем расходиться во мнениях относительно того, нравится ли нам объявление, спасибо @davidfowl @DamianEdwards и @shanselman за то, что они потратили время на обсуждение. Это еще одно доказательство возросшей заинтересованности и открытости.

Я уверен, что некоторые будут спорить о сроках и т. д., но это прогресс.

Пример:
2017 asp.net хочет функцию A.
Netstandard 2018 реализует Feature A. Мы получаем Feature A на ns.

Команда говорит, что сетевое ядро ​​не должно быть основано на сетевом стандарте, поэтому:
2017 asp.net хочет функцию A
Команда aspnet 2017 реализует функцию A. Asp.Net Core получает функцию A на netcore.
2018 netstandard реализует функцию A. мы получаем функцию A на ns.

то, что они должны были сделать, это:
Команда aspnet 2017 создает функцию, необходимую в lib X, которая поддерживает netstandard2.0. Таким образом, aspnet работает со всем, на чем работает .netstandard, и пользователи могут затем запускать его на .net full, поскольку lib X можно использовать и на .NET full (это просто установка nuget).

Вместо этого они этого не делают, они заставляют lib X быть только ядром .NET (иначе, зачем вообще этот поток/решение). Если lib X настолько продвинута, что ей нужны функции CoreCLR, Microsoft должна спросить себя, почему эти расширенные функции не перенесены в полную среду CLR .NET.

В целом это похоже на политику, когда MS нуждается в быстроразвивающемся ядре .NET/aspnet, чтобы предоставить клиентам Azure стек, который можно использовать в контейнерах на Azure, чтобы он конкурировал с контейнерами на основе JVM/NodeJS в облаке AWS или Google. С точки зрения их бизнеса я даже могу это понять. Но это показывает, что MS не имеет приоритета в отношении .NET full, чтобы двигаться вперед быстрее, поскольку она не выделяет достаточно ресурсов на .NET full, чтобы не отставать от ядра .NET. Посмотрите на количество API, полностью добавленных в .NET за последние 2 года. Говорит ли это о том, что над этим работает большая команда?

Нет.

Microsoft продает большую систему баз данных SQL Server Enterprise. Он поставляется с причудливыми функциями шифрования. Не поддерживается в ядре .NET. Получайте удовольствие, продавая .NET core 2.0 предприятиям, которые являются потенциальными клиентами этой дорогой системы баз данных.

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

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

Поскольку о версиях плохо сообщается, люди считают, что это только последняя часть, которая обновляется и движется вперед, в то время как asp.net и asp.net core (.net) застряли.
Поскольку у нас нет возможности проверить, будет ли библиотека работать в netstandard2.0, не попробовав, очень рискованно работать с полным ядром в новом проекте. Таким образом, они получают либо asp.net (старый), либо asp.net core (тоже старый).
И поскольку оба старые, имеет смысл просто использовать system.web и старый asp.net. Поскольку они это знают, и поскольку ядро ​​​​asp.net в любом случае является EOL, зачем беспокоиться.

В итоге у нас остаются только самые смелые, выбирающие ядро, а остальные идут со старым, но стабильным system.web. И мы навсегда застрянем в еще более раздробленной экосистеме.

PS: я формулирую это как с текущим чувством. Это ядро ​​​​asp.net 1.x является «старым и устаревшим» по сравнению с 2.x. Это не факт, но люди так думают.

@davidfowl

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

Это уже происходит, и мы в порядке с этим. Документ Версии обычно заполняется _vNext_. И это нормально. Вместо того, чтобы ждать, пока все платформы сравняются, прежде чем расширять стандарт, я бы предпочел, чтобы стандарт был определен на несколько версий раньше, и смотрел, как платформы догоняют его. Люди могут даже участвовать в определении и реализации. И если ASP.NET Core ориентируется на стандарт для своих выпусков, в тот момент, когда платформа и архитектура реализуют этот новый стандарт, пакет будет доступен. Новые стандартные версии могут поступать через обновления или пакеты VS.

То, как это представлено, хотя .NET Standard не похоже на спланированное сообществом усилие. Это скорее снимок выполненных контрактов, прошедших проверку. И если крупные проекты не нацелены на него, не будет такого большого планирования его выпусков.

Мы делаем то же самое

О, хорошо. Разделенное страдание — лучшее страдание. Файлы Csproj и sln с информацией о платформе/конфигурации действительно раздражают, кстати, потому что комбинации сборки не всегда объявляются — они выводятся. Таким образом, VS может подумать, что у меня больше комбинаций сборки, чем существует на самом деле, потому что предполагается, что каждая возможная комбинация важна. И у меня должны быть дополнительные разделы в файле, которые не были бы нужны, если бы я мог просто объявить комбинации платформы/конфигурации. Например, как вы можете использовать такие функции, как Substring в элементах csproj PropertyGroup для упрощения пользовательских свойств, но эти условия используются при определении конфигураций сборки, поэтому вы должны иметь полные строковые значения. Такие вещи не должны доставлять столько хлопот, как они есть.

Честный вопрос (это я спрашиваю, а не Microsoft): вы предпочитаете совместимость новым функциям? Если да, то почему стоит выбрать ASP.NET Core?

Лично нет. Пока есть способ делать то, что мне нужно, я не возражаю против переписывания кода, если это не требует огромных усилий с небольшой пользой или PITA для тестирования. Так что я бы выбрал то, что имеет наибольший импульс и потенциал. Но мне приходится работать с проектами по нескольким технологиям — Win32, COM, CORBA, ADO.NET, нескольким механизмам отчетности, различным веб-API, встроенным браузерам, таким как CEF/Firefox/IE (конечно, без преимуществ, поскольку они не поддерживаются) и несколько специфичных для поставщика вещей, которые я не буду стыдить. Я реализую то, что могу, как плагин, но по большей части я женат на наименьшем общем знаменателе в исполняемом файле хоста. Работа с таким количеством технологий раздражает, но они статичны. Вот как много вещей для настольных компьютеров / серверов. Пока у меня есть инструменты для взаимодействия, я могу обойтись. Но чем меньше устаревших фреймворков я помню, тем лучше.

ASP.NET, тем не менее, является частью веб-стека, а веб-стек — это то, что, по моему мнению, необходимо постоянно обновлять. У него другой вариант использования, и есть неудачное ожидание использования более новой платформы для работы в Интернете, если только нет веской причины не делать этого или значительная несовместимая кодовая база. Я стараюсь держать это в курсе, потому что веб-стандарты меняются быстро и значительно. Большинство людей, идущих в ногу с Интернетом, придерживаются новых технологий, и внедрение новых вещей в старые стеки может быть довольно болезненным. Особенно в ситуации, когда ASP.NET конкурирует с PHP и Node, я должен поддерживать более современный стек, чтобы привлекать таланты и интерес. Я бы хотел меньше работать в Интернете, но, к сожалению, это новый пользовательский интерфейс. Я надеялся, что соблюдение стандарта позволит мне получить лучшее из обоих миров, но это похоже на ограниченное по времени предложение.

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

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

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

• Мы определили строки как одну из основных вещей, которые мы хотели бы попробовать решить в .NET Core, есть множество идей, но одна из них — сделать строку по умолчанию utf8 (множество проблем с совместимостью, но следуйте за мной здесь).
• Еще одна вещь, которую мы хотели бы исправить, — это возможность брать дешевые фрагменты массивов/строк, любую часть непрерывной памяти. Мы добавили Span<T> и смотрим на Buffer<T> , чтобы представить это. Это может означать, что String и Array реализуют новые интерфейсы, которые позволяют использовать срез, требующий нулевого распределения.
• Это приводит к новым методам для String, которые позволяют выполнять разбиение без выделения массива каждый раз.
• Это приводит к перегрузкам Int, UInt и т. д. (TryParse), которые принимают Span<char> и Span<byte> .
• Это приводит к новым процедурам кодирования, которые занимают Span<byte> .
• Buffer<T> и Span<T> позволяют унифицировать представление памяти, и мы хотим обновить сетевой стек, чтобы разрешить передачу предварительно закрепленных буферов, которые занимают Span<T> или Buffer<T> .
• Kestrel реализует HTTP2 в период времени 2.x (в настоящее время нацелен на 2.1), и для этого требуются новые API в потоке SSL для выполнения ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Http-клиент на .NET Core поддерживает дуплексную потоковую передачу, что позволит реализовать конечные точки потоковой передачи через http в signalr с помощью одного http-запроса без веб-сокета.
• Мы разветвили реализации парсера заголовков из HttpClient и System.Net.Http и переименовали их (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers), чтобы мы могли их улучшить. и пусть они поддерживают как .NET Framework, так и .NET Core. В .NET Core есть копия этих улучшений, которая не вернулась, потому что в них нет необходимости (мы не могли их использовать).
• Существует множество новых примитивов многопоточности, для которых требуется новый API, который будет освещать новые сценарии, если мы сможем их использовать (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ автор%3Adavidfowl+label%3Aarea-System.Threading), это лишь некоторые из вещей, которые я лично зарегистрировал.

Не имея возможности переработать базовые примитивы, нам предлагается разветвлять их и создавать вещи, которые выглядят как они, но ими не являются. Именно поэтому у нас есть собственный небольшой BCL в ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

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

@ФрансБума

NET full, чтобы двигаться вперед быстрее, так как он не выделяет достаточно ресурсов на .NET full, чтобы не отставать от ядра .NET. Посмотрите на количество API, полностью добавленных в .NET за последние 2 года. Говорит ли это о том, что над этим работает большая команда?

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

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

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

В настоящее время, если вы начали портировать/использовать ASP.NET Core на .NET Framework, похоже, у вас есть три варианта:

1. Перенесите весь свой код и зависимости в .NET Core и перейдите на ASP.NET Core 2.x.
   
   
   
   • Это было бы оптимальным решением, но оно может потребовать тонны работы, а для некоторых это может даже выйти из-под контроля из-за сторонних библиотек.
   
   
2. Оставайтесь на ASP.NET Core 1.x и .NET Framework и надейтесь, что вы сможете сделать 1. до того, как они перестанут поддерживаться.
   
   
   
   • Это довольно рискованно. В течение года (или двух, или трех? кто знает?) вы рискуете работать на неподдерживаемой платформе.
   
   
3. Вернуться к ASP.NET 4.x
   
   
   
   • Несмотря на то, что этот вариант оставляет вас поддержанным, вы будете «возвращаться назад» и отменять уже начатую работу. А также, давайте посмотрим правде в глаза; эта платформа не будет получать много любви в будущем.
   
   

Если бы вы знали заранее и могли спланировать это, я думаю, что и 1., и 2. являются достойными альтернативами. Проблема в том, что обе альтернативы имеют довольно много неизвестных. Как насчет библиотеки А? Что насчет библиотеки Б? Будет ли когда-нибудь портирована библиотека A?

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

@khellan (в вашем гипотетическом решении)

1. Переход на ASP.NET Core 2.0 в .NET Framework
   
   
   
   • Это довольно рискованно. В течение года вы рискуете работать на неподдерживаемой платформе.
   
   

@davidfowl

Честный вопрос (это я спрашиваю, а не Microsoft): вы предпочитаете стабильность и совместимость новым функциям? Если да, то почему стоит выбрать ASP.NET Core?

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

Экосистема, такая как .NET (старая и/или базовая) или Java, выбирается предприятиями. И когда они принимают решение, они прикладывают много усилий для разработки кода для этой платформы/экосистемы.

Например, один из наших клиентов уже много вложил в ASP.NET Core. На основе предыдущих анонсов и реализованных идей .NET Core был написан код. Этот новый код (ASP.)NET Core, который мы (мучительно) написали с командой в ходе первоначальной разработки (ASP.NET Core), начиная с его создания, представляет собой набор серверов и клиентских библиотек с довольно большим количеством бизнес-логики.
И этот код, помимо работы на Linux-сервере, предоставляющего услуги, в настоящее время также используется в наборе очень старых приложений, которые взаимодействуют с этими службами, и это чертовски смесь WPF/Windows Forms/C++/CLI и обычных C++ (включая материал DirectX).

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

Возвращаясь к вопросу: бизнес выбрал бы .NET Core как «.NET, теперь также и для XPlat», ожидая при этом той же совместимости и стабильности, которые .NET дала нам за последние 17 лет. И, честно говоря, это единственная причина для .NET Core. Если бы вы этого не хотели, вы бы использовали Node.js или даже Java. Оба теперь гораздо более зрелые и XPlat, чем .NET Core.

И, просто чтобы уточнить немного больше: .NET Core был крутым и быстро развивающимся на ранних стадиях с project.json и всем остальным. А потом из соображений "совместимости с .NET" у нас забрали project.json в пользу Msbuild и снова .csproj. А теперь и плюсы именно этой "совместимости с .NET" тоже отбирают, в пользу.. чего именно?

@гингтерс

Во-первых, отличный ответ!

Почему ASP.NET Core: Просто потому, что он работает на OS X и Linux.

Исходя из этого, кажется, что MVC 5 в моно — это то, что вы действительно хотели, верно?

Возвращаясь к вопросу: бизнес выбрал бы .NET Core как «.NET, теперь также и для XPlat», ожидая при этом той же совместимости и стабильности, которые .NET дала нам за последние 17 лет. И, честно говоря, это единственная причина для .NET Core. Если бы вы этого не хотели, вы бы использовали Node.js или даже Java. Оба теперь гораздо более зрелые и XPlat, чем .NET Core.

И, просто чтобы уточнить немного больше: .NET Core был крутым и быстро развивающимся на ранних стадиях с project.json и всем остальным. А потом из соображений "совместимости с .NET" у нас забрали project.json в пользу Msbuild и снова .csproj. А теперь и плюсы именно этой "совместимости с .NET" тоже отбирают, в пользу.. чего именно?

В этом, собственно, и суть вопроса. На основании вашей оценки:

Этот новый код (ASP.)NET Core мы (мучительно) написали с командой в ходе первоначальной разработки (ASP.NET Core).

Вы действительно просто хотели существующую .NET Framework для Linux со старой доброй совместимостью с ASP.NET 4.x. Это справедливое резюме?

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

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

Если вы хотите использовать новые функции в следующей версии Desktop, вам необходимо обновить весь компьютер до этой новой версии, и это повлияет на все на этом компьютере, а не только на приложение, которое хочет использовать новые функции. Это нормально, если у вас есть выделенный сервер для одной цели; но не в том случае, если на одном сервере запущено много приложений, которые обновляются с разной скоростью (или вообще никогда не обновляются!)

@davidfowl написал:

Фреймворки сами решают, хотят ли они работать на .NET Framework, UWP, .NET Core, моно и т. д. Это выбор. Orleans не поставляется с .NET Core. ASP.NET Core делает. Это одни и те же продукты.

В случае Orleans мы поддерживаем .NET Standard 1.5 в наших сборках «2.0 Technical Preview», но ждем .NET Standard 2.0, чтобы иметь возможность сделать стабильный выпуск. В настоящее время я не вижу для нас каких-либо блокаторов - меня беспокоит только будущее расхождение. Однако это расхождение должно произойти в какой-то момент.

👍 Большое спасибо, @davidfowl и компания, за то, что вы остались и ответили на все вопросы!

NET full, чтобы двигаться вперед быстрее, так как он не выделяет достаточно ресурсов на .NET full, чтобы не отставать от ядра .NET. Посмотрите на количество API, полностью добавленных в .NET за последние 2 года. Говорит ли это о том, что над этим работает большая команда?

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

это игнорирует тот факт, что вы можете выпускать библиотеки, от которых зависите, как пакеты netstandard2.0, поэтому aspnet также может работать на .net в полном объеме. Кроме того, внесение изменений в .NET full сопряжено с риском, но, пожалуйста, не делайте вид, что это ужасно организованная куча кода, где одно изменение может все разрушить.

Несмотря на все это, нам все еще удается делать функции.

Да, как и любой другой разработчик .NET ;) Как только вы что-то выпускаете, вы застряли с этим API, у всех нас есть это. Однако вы хотите сократить путь (как команда ASPNET делала много раз раньше!) и двигаться без этого бремени. Но это не сработает в конце концов.

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

Я думаю, здесь у нас есть суть вопроса, не так ли? Основная команда .NET может делать все, что хочет, без общения с гигантом «WinDiv». Почему Microsoft не решает эту внутреннюю политическую хрень своими силами и не следит за тем, чтобы .NET full + .NET core правильно версионировались/перемещались без политики Windows?

Кстати, все еще интересно, как вы будете продавать API шифрования SQL Server Enterprise пользователям .NET core 2.0.

Кроме того, я должен добавить; Я очень впечатлен тем, как долго продолжается эта ветка, с таким количеством людей, оставаясь при этом цивилизованным ❤️ Такое не каждый день увидишь в интернете 👏 Может быть, экосистема .NET OSS все-таки растет? 😉

это игнорирует тот факт, что вы можете выпускать библиотеки, от которых зависите, как пакеты netstandard2.0, чтобы aspnet мог работать и на .net в полном объеме.

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

Он большой и существует уже давно. Как и в любой устаревшей системе, некоторые части лучше, чем другие. Это не делает код менее надежным, но делает некоторые части практически невозможными для изменения. Есть так много забавных историй, которые ветераны могут рассказать вам о том, как исправления ошибок в одних областях ломали неясные сценарии в приложениях в других частях. Это запутанно, вот что происходит, когда границы зависимости не определены четко. Вам даже не нужно мне верить, просто зайдите на сайт referencesource.microsoft.com. Обновления на месте — это причина, по которой нам нужно добавить переключатель конфигурации для каждого потенциально критического изменения в .NET Framework. Это физика, она просто не может двигаться так быстро.

Да, как и любой другой разработчик .NET ;) Как только вы что-то выпускаете, вы застряли с этим API, у всех нас есть это. Однако вы хотите сократить путь (как команда ASPNET делала много раз раньше!) и двигаться без этого бремени. Но это не сработает в конце концов.

Мы любим ярлыки! Разработчики ленивые 😄 . Мы также хотим действительно улучшить наш .NET Core, не нарушая того, что представляет собой .NET Framework. Возможно, нам стоило переименовать его во что-то другое, например, Sparkle 😄 .

Я думаю, здесь у нас есть суть вопроса, не так ли? Основная команда .NET может делать все, что хочет, без общения с гигантом «WinDiv». Почему Microsoft не решает эту внутреннюю политическую хрень своими силами и не следит за тем, чтобы .NET full + .NET core правильно версионировались/перемещались без политики Windows?

Прочитайте мой другой ответ о физике.

Кстати, все еще интересно, как вы будете продавать API шифрования SQL Server Enterprise пользователям .NET core 2.0.

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

@khellang , лол, это потому, что проблемы GitHub еще не привлекли троллей, ненавидящих MS. В настоящее время Twitter является их средой для того, где еще нет отрицательных голосов :)

@davidfowl

Вы действительно просто хотели существующую .NET Framework для Linux со старой доброй совместимостью с ASP.NET 4.x. Это справедливое резюме?

Нет, не совсем. Нашему клиенту требовались полностью новые / блестящие (микро) сервисы в дополнение к их существующим .NET 4.x (когда мы начинали, они были 3.5) настольных приложений Windows.

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

Кроме того, некоторые из совершенно новых серверов ASP.NET Core работают не только в Linux, но и в качестве служб Windows с Topshelf (поверх полной платформы 4.6).

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

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

Итак, пока .NET Core 1. поддерживается так же, как .NET 4.6, и существует линейный путь обновления до .NET Core x, когда выйдет .NET 5, и код .NET Core x может работать на .NET Core x. NET 5, тогда все в порядке.

@gingters Используете ли вы функции .net, отличные от netstandard2.0, в службах asp.net?

Если нет, то библиотеки должны просто работать. Но я предполагаю, что вы говорите о вещах, которых нет в netstandard2.0.

@davidfowl Будут ли библиотеки C++/cli работать в netcoreapp 2.0? У нас есть старые сторонние сборки C++/CLI, которые не будут заменены в ближайшее время.

@davidfowl написал:

Честно говоря, в ASP.NET Core 2.0 не так много новых функций.

В таком случае, почему это очень разрушительное изменение сейчас?

@qrli C++/CLI не работает в CoreCLR. Вот некоторые сведения о том, почему он не будет поддерживаться: https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753.

Дайте 4 года поддержки 1x (перенос как можно большего количества из 2x) и вперед и быстро с 2x. Городской автомобиль для медленного городского движения и Феррари для шоссе. У нас много конкурентов за пределами мира .net.
Если ASP.Net Core добьется успеха, я уверен, что MS предоставит ресурсы для поддержки 1x в течение 4 лет. В основном изменится культура.

@ idg10 Это действительно не так. 2.x в значительной степени похож на 1.x с производительностью, доступной только в ядре. Я думаю, что единственной важной особенностью является Razor Pages.

Таким образом, использование версии 1.x не означает, что вы используете устаревшую версию. Но об этом не очень хорошо сообщают.

В таком случае, почему это очень разрушительное изменение сейчас?

думаю, это в значительной степени резюмирует это https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

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

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

@gingters Не уверен, что понимаю.

Если ваши настольные библиотеки работают с netstandard2.0, они также должны работать на ядре. (если они вызывают вещи wpf и т. д., они, конечно, не будут)
Если это так, вы сможете использовать asp.net core 2.0.

Если ваши настольные библиотеки дают сбой на ядре, потому что они используют вещи, не входящие в netstandard2.0. Тогда я понимаю, почему вам нужно оставаться на 1.x. И я понимаю, почему короткий EOL — это проблема.

Был бы 1.x более простым/лучшим выбором, если бы вы знали, что 2.x содержит только основные перфомансы (это означает, что 1.x не устарела по сравнению с 2.x). И что 1.x будет получать патчи и поддерживаться * лет?

@hallatore Все наоборот. Старое приложение: сочетание Windows Forms, WPF, C++/CLI, обычного C++, DirectX, миллионов строк кода и т. д., работающее на полной платформе 4.6.

В .NET Core: новые библиотеки бизнес-логики (с использованием также других библиотек, например версии Serilog для .NET Core), библиотеки абстракций + службы + клиентские библиотеки для этих служб. Службы должны работать в Linux и как службы Windows (в настоящее время Topshelf на полной платформе .NET 4.6, однако, как только поддержка службы Windows появится в Core, это может быть изменено).

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

@gingters Вы по-прежнему можете иметь в своем решении проекты общих библиотек, ориентированные на netstandard _min(usable)_, и использовать эти библиотеки из своего кода ASP.NET Core 2.0, а также упаковывать их для использования в WPF, Xamarin, UWP и т. д.

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

Исходя из этого, кажется, что MVC 5 в моно — это то, что вы действительно хотели, верно?

@davidfowl Я имею в виду, давай. Это пренебрежительный и откровенно оскорбительный ответ. Может ли кто-нибудь в MS подтвердить, что хотя бы одному разработчику назначен Framework ASP? Я не пытаюсь быть придурком, но иногда кажется, что с сообществом разговаривают снисходительно.

Нет никаких оснований считать .Net Core и ASP.Net Core одним и тем же продуктом. Там не было никаких сообщений, чтобы поддержать это вообще. Особенно, если учесть, что Mono перешла под крыло Microsoft _после_ анонса .Net Core. О нем всегда сообщалось, что это меньшая, более шустрая xplat-версия .Net. Мало того, мы все помним дни, когда ASP.Net Core был на самом деле ASP.Net 5 и должен был работать везде. Черт возьми, это изменение произошло чуть более полутора лет назад.

Действительно ли история HTTP с собственным хостингом в netstandard20 «использует Kestrel 1.x»? Я не уверен, что ребята из Нэнси будут сильно заботиться об этом, и я тоже. ASP.Net 2.x может быть инкрементным с точки зрения функций, но Kestrel 2 имеет серьезное преимущество в производительности, которое мы могли бы серьезно использовать в тот день, когда он выходит.

@davidfowl

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

Я думаю, что это интересный комментарий. Я помню, как смотрел запись старой конференции NDC, в которой @davidfowl и @DamianEdwards разбирали устаревшие хламы в ASP.NET 4, которые вы действительно хотели оставить позади — было действительно увлекательно заглянуть внутрь этого черного ящика кода.

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

Я не знаю, какой правильный ответ. Но я знаю, что для наших собственных приложений мы будем использовать полный фреймворк и ASP.NET4/MVC5 в обозримом будущем (у нас все еще есть кусок WebForms, который не будет переписан в течение некоторого времени!). Я надеюсь, что MVC5 получит некоторую любовь теперь, когда он _наконец_ перемещен на GitHub — я даже готов пожертвовать своим временем и усилиями, чтобы сделать его лучше (например, лучшая поддержка асинхронности, улучшения производительности и т. д.).

@qrli Предприятия все еще имеют полную версию .NET 4.5 для работы на своих веб-фермах Windows Server 2008 R2 IIS 7.5. Этого у них никто не отнимет.

@mattnischan

Действительно ли история HTTP с собственным хостингом в netstandard20 «использует Kestrel 1.x»? Я не уверен, что ребята из Нэнси будут сильно заботиться об этом, и я тоже.

HttpListener является частью netstandard20, поэтому и netcore20 ничего не убирает на этом фронте, переходя на netcore20.

HttpListener является частью netstandard20, следовательно, и netcore20.

И я полагаю, что могу ожидать тех же запросов в секунду от HttpListener ?

@markrendle Верно. На данный момент.

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

@mattnischan

HttpListener является частью netstandard20, а значит, и netcore20.

И я полагаю, что могу ожидать таких же запросов в секунду от HttpListener?

Итак, Нэнси — это .NETStandard 1.6, поэтому вы можете использовать его на Core 2.0 и использовать Kestrel 2.0. Лучше?

@gingters Я бы посоветовал перейти этот мост, когда вы к нему подойдете.

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

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

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

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

Итак, вам нужен веб-сервер, который работает так же быстро, как Kestrel, и ваше единственное конкретное требование — это не Kestrel?

Итак, Нэнси — это .NETStandard 1.6, поэтому вы можете использовать его на Core 2.0 и использовать Kestrel 2.0. Лучше?

@markrendle @benaadams Нет, я думаю, вы неправильно поняли, и опять же, не пытаясь быть придурком, просто указав, что есть и другие клиенты частей ASP.Net Core, которые не являются целым. Я просто хотел бы разместить нашу производственную платформу поверх Kestrel 2.0, когда она выйдет, и наша производственная платформа может быть какое-то время на Framework. Я не могу настроить таргетинг на netcoreapp20.

Нэнси может быть netstandard16, но это не имеет значения, потому что я не могу использовать Kestrel 2.0, кроме как на Core 2.0. Я понимаю, что это специфично, и, возможно, ответ действительно таков: «Затем напишите свой собственный веб-сервер, который работает на платформе, такой же быстрой, как Kestrel 2. Kestrel предназначен только для ASP.Net». Но я бы не хотел, чтобы это было сообщением.

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

@mattnischan Да, я понял, что вы имели в виду, и удалил этот комментарий :)

@стефанолсон

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

Если вы ориентируетесь на .NET Standard со своими библиотеками, вы можете использовать их как в Desktop, так и в Core. Для библиотек, предназначенных для .NET Standard, у вас есть поддержка универсальных платформ: Desktop, Core, Mono, Unity, UWP, Tizen и т. д.

Приложение ASP.NET — это исполняемый файл; конечная точка, это не библиотека. Окончательный вывод: приложение/исполняемый файл ASP.NET должно работать на платформе. В конечном итоге любая из его библиотек платформы будет использоваться приложением ASP.NET, поэтому нет никаких преимуществ в том, что они не являются той же целью, что и платформа.

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

Некоторые предметы можно использовать снаружи; поэтому Wyam использует Razor для создания статических сайтов; Razor в настоящее время является .NET Standard 1.3, поэтому его использование вне Core в настоящее время не является проблемой.

Есть несколько крайних случаев, упомянутых выше:

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

Запуск веб-приложения, встроенного, например, в приложение UWP; однако, если бы рабочий стол по-прежнему поддерживался, но был изменен на версию 4.7.1, вы все равно оказались бы в той же ситуации, поскольку UWP в настоящее время не поддерживает 4.7.1, и к тому времени, когда это произойдет, для ASP.NET потребуется 4.7.2, а затем 4.7. 3 и т. д. Это было бы сизифовой задачей, так как другие платформы никогда бы ее не поймали; так что это будет просто занятая работа без особого смысла?

Да, я понял, что вы имели в виду, и удалил этот комментарий :)

Не беспокойтесь, добрый сэр. 👍

@davidfowl

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

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

Ранее я оценивал начальную миграцию нашего фреймворка (очень похожая история на то, что описал @benaadams ) на ядро ​​​​core/asp.net в два этапа: перенести веб-часть (которая сейчас находится на mvc/webapi) на ядро ​​​​asp.net и сохранить полный .net, а затем перенесите все остальное на ядро, когда все зависимости будут иметь соответствующие реализации для ядра. В настоящее время нас блокирует поставщик Oracle ADO и поставщик ADO Postgres (могут быть другие несовместимости в corefx, которые мы еще не изучали). Теперь этот план мертв. Так что нам приходится сидеть и ждать миграции зависимостей, отказываясь от всего нового в мире Core. И все это только из-за того, что кто-то в MS решил, что нам нужна «быстро движущаяся» платформа.

@markrendle Приложение не сломается только из-за этого. Дело в другом:
Поскольку .NET Core 2 отказался от поддержки полного фреймворка (там, где он отлично работал в версии 1, и это от Microsoft, где вы не ожидаете, что такая базовая, элементарная функция будет удалена при обновлении до новой версии), также ваш зависимости могут прекратить поддержку этого сценария раньше, чем позже.
Кто-то обнаруживает критическую проблему безопасности в одной из используемых библиотек, и для версии, на которой вы застряли, не выпускается обновление, поскольку более новые версии больше не поддерживают вашу среду выполнения. Теперь, поскольку ваше приложение используется в очень регулируемой среде, вам необходимо предоставить план действий в чрезвычайных ситуациях, в котором объясняется, что именно вы будете делать при обнаружении критической проблемы безопасности и как развернуть это исправление, чтобы люди не пострадали или еще хуже. Ответ «Ну, мы ничего не можем сделать» приведет к аннулированию вашего разрешения на отправку этого приложения.

@gingters Послушайте, дело в том, что вы должны делать свой технологический выбор на основе информации, которая в настоящее время доступна, и характера рынка, на котором работает ваша компания. При всем желании вы не сможете учесть все случайности, как бы бюрократам и регуляторам мира ни хотелось притворяться, что вы можете это сделать. Что, если Microsoft будет приобретена Apple в результате враждебного поглощения, а .NET будет полностью прекращен в пользу Swift? Что делать, если сильное шифрование объявлено незаконным в одной из стран, в которые вы продаете, и все программные стеки, включающие SHA256, запрещены? Что, если Николас, Джеймс или _вставьте-вставьте-имя-обслуживающего-Autofac-здесь_ решат переехать на Марс и стать фермерами? Что, если магнитные полюса поменяются местами и каждый бит записанных в цифровом виде данных будет стерт?

В качестве фактического ответа на вопрос о том, что вы, как компания, говорите, что будете делать в случае обнаружения критической проблемы безопасности в JSON.NET (например), в отсутствие доступного официального обновления, единственный возможный ответ: «мы разветвим и исправим JSON.NET», что, как я предполагаю, уже является ответом на вопрос о том, что вы будете делать, если Джеймс Ньютон-Кинг по какой-либо причине заболеет. По моему предыдущему опыту работы на такого рода рынках, существовали договоренности об условном депонировании исходного кода в проприетарных пакетах на такие случаи; что делать с пакетами с открытым исходным кодом, тривиально по сравнению с этим.

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

«быстро двигаться» может быть преувеличением; исходя из предыдущего графика выпуска Full Framework, его лучше было бы сформулировать как «без добавления дополнительной задержки на 1–2 года» в отгрузку. Это сумасшедшее количество времени в веб-мире.

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

@davidfowl и @DamianEdwards Я думаю, что вся эта путаница возникла из-за того, что ASP.NET Core 1.x может работать на .NET Framework. Это создало предположение, что ASP.NET Core является развитием ASP.NET 4/MVC5; заставляя людей переходить на него, думая, что они получат все преимущества (скорость и новые функции), сохраняя при этом обратную совместимость.

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

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

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

@markrendle Да, это гипотетически, но, к сожалению, бюрократия реальна. И да, вы не можете (и не должны) учитывать все возможные варианты. Только для тех, кого вы можете предвидеть.

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

И да, разветвление и резервное копирование исправлений — это одно из возможных решений, однако этого следует избегать, насколько это возможно. Если бы команда .NET Core сказала что-то вроде «Эй. Послушайте, мы не собираемся работать на полной платформе, не полагайтесь на это», или, что еще лучше, никогда не сделала бы это возможным, вся эта дискуссия в этом не было бы необходимости, поскольку заказчик просто не решился бы инвестировать в новые вещи поверх .NET Core.

@gingters Я думал, что мы были в той точке, когда вы были счастливы запускать свои веб-биты ASP.NET Core в .NET Core 2.x или более поздней версии и использовать .NET Standard 2.x для обмена библиотеками между Core и Full/UWP/что угодно . Потому что, если бы эти библиотеки отказались от поддержки .NET Standard 2.x в пользу только .NET Core 2.x, то они отказались бы и от полной поддержки .NET, и вы в любом случае оказались бы в затруднительном положении.

@markrendle Вплоть до того момента, когда у нас возникла критическая проблема в одном из битов ASP.NET Core, который нам нужно использовать в общем материале после того, как 1x больше не поддерживается.

@gingters , к счастью, это открытый исходный код, и вы можете поддержать себя (или заплатить третьей стороне), если это необходимо!

@markrendle нет. чистые унаследованные проекты мертвы. корпоративные проекты, как правило, представляют собой большую смешанную кодовую базу, которая содержит код/библиотеки от десятилетий назад до новых. быть netcoreapp означает только то, что вы удалили возможность микшировать. так что мы больше не можем перейти на вашу модную новую версию, но заблокированы на старой версии. и коллеги по борьбе с MS с радостью скажут мне: «Я же говорил тебе…», а затем подтолкнут нас к переходу на решения Google.

я не выступаю за поддержку netfx навсегда. но я твердо уверен, что netfx должен поддерживаться ядром asp.net как минимум через 2 года. не только 1.х, но и 2.х.

@qrli Эти «корпоративные проекты ... большая смешанная кодовая база, содержащая код / ​​библиотеки, датируются десятилетиями назад и являются новыми». все, что не так с корпоративными проектами и что нужно остановить. Жаловаться на то, что новая технология мешает вам бросать больше кусков грязи в большой шар отчаяния, скрепленный прокладками, проволокой для связывания и отрицанием, — это все равно, что жаловаться на новый промышленный станок для лазерной резки с функциями безопасности, которые не позволяют вам наклоняться и резать. важные части себя.

@бенаадамс

«быстро двигаться» может быть преувеличением; исходя из предыдущего графика выпуска Full Framework, его лучше было бы сформулировать как «без добавления дополнительной задержки на 1–2 года» в отгрузку. Это сумасшедшее количество времени в веб-мире.

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

Это политическое/организационное ограничение, а не техническое. Посмотрите, как движется JVM/Java. Если они вообще двигаются. Все еще актуальна, намного больше, чем .NET сегодня. Таким образом, люди выбирают Java/JVM не по причине «быстрого движения». Напротив. Они выбирают Java/JVM, потому что в ней отсутствуют все недостатки, связанные с «быстрым продвижением»: это стабильная, надежная платформа, в которую ваши инвестиции не пропадут впустую через 1-2 года.

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

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

Я не знаю, каково решение в краткосрочной перспективе, но в долгосрочной перспективе оставить .NET разделенным на два основных отдела (.net full с окнами, .net core с devdiv) без каких-либо точек соприкосновения/целей, кроме тех же самых. работодатель не сулит ничего хорошего для нас, посторонних.

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

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

Это также не должно означать, что _my_ приложения должны работать медленнее и обходиться дороже.

Выполнив анализ переносимости наших активно используемых библиотек, которые по-прежнему нацелены на .NET 4.x на ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) и man, эти библиотеки даже близко не способны ориентироваться на netstandard20 .

Либ | Процент
---------- | ---------
EF6 | 62,74
NHibernate | 67,39
NServiceBus | 65,68

И все еще огромные пробелы в отсутствующих API. EF Core по-прежнему имеет большой разрыв с EF6, и мы по-прежнему используем NHibernate, когда в нем есть важные функции, которых нет в EF6. NServiceBus мы используем в любом проекте, который занимается обменом сообщениями.

Фух.

@маркрендл

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

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

Послушайте, никто не говорит «новые технологии: это плохо!». Речь идет о поиске новых технологий, не осознавая последствий, которые они влекут за собой. Нам всем нравится работать с новейшими технологиями и не беспокоиться о старом хламе, кому это нужно? Однако реальность говорит о другом. Если вам нужно работать только с новейшими битами и не нужно заботиться о старом дерьме, хорошо для вас! К сожалению, мы, печальные рабочие дроны, в окопах вынуждены жить с другой реальностью. Вас бы устроило, если бы вы хотя бы признали, что для МНОГИХ людей реальность такова, что они не могут ее изменить, они не могут построить другое будущее, это то, с чем им приходится работать.

@markrendle Я не совсем уверен, что ты предлагаешь? Отказаться от наших 15 миллионов строк рабочего кода C# и написать все заново? Мы планировали переход (медленный) на netstandard 2.0 и, надеюсь, получить доступ к таким вещам, как Span и т. д., когда это произойдет, но такие проблемы заставляют меня сомневаться в том, что это разумно.

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

@FransBouma Значит, мы все должны страдать, потому что предприятия хотят делать глупости? Я не должен получать приятные вещи, потому что многомиллионные проекты госсектора для них еще не готовы? Как это работает?

@markrendle Что глупого в желании сохранить работающий код?

Они выбирают Java/JVM, потому что в ней отсутствуют все недостатки, связанные с «быстрым продвижением»: это стабильная, надежная платформа, в которую ваши инвестиции не пропадут впустую через 1-2 года.

И вы можете использовать System.Web практически вечно; он встроен в Windows, что означает, что он, вероятно, никогда не исчезнет. Вы не получите много стабильного и надежного, чем это.

ASP.NET Core 1.x -> ASP.NET Core 2.x; все API практически одинаковы, главное изменение — отказ от поддержки .NET Framework. Он даже меняет семвер на перерыв 😱

ASP.NET Core 1.x работает на .NET Core 2.x и .NET Framework, поддерживает .NET Standard 2.x (через .NET Core 2.x); и имеет тот же API, что и ASP.NET Core 2.x, так что это стартовая версия.

ASP.NET Core 2.x — это выпуск перерыва. Он по-прежнему поддерживает .NET Standard 2.x (через .NET Core 2.x), и между ASP.NET Core 1.x и ASP.NET Core 2.x мало что изменилось с точки зрения API; но сбрасывает .NET Framework.

Может ли быть альтернатива:

• ASP.NET Core идите вперед и работайте над чем-то вроде netstandard3.0 (может быть 2.x) и просто ускоряйте версию netstandard. Вроде раз в квартал.
• Следующий выпуск NetFx может снова перейти к поддержке netstandard3.x всякий раз, когда будет следующий выпуск. Это даже не обязательно должен быть новейший стандарт.

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

Просто плевок. Я уверен, что это было поднято.

@bencyoung Я просто предполагаю, что немного эгоистично настаивать на том, чтобы весь мир вращался вокруг ваших 15 миллионов строк рабочего кода C # (который, кстати, не перестанет работать). Таким образом, вы не можете использовать ASP.NET Core 2.0. У вас по-прежнему есть полная инфраструктура ASP.NET только для Windows, которая имеет устаревшую поддержку, проходящую через нее, как Брайтон через скалу. Итак, есть новая игрушка, с которой вы не можете играть, потому что для вас экономически невыгодно портировать свой код и рефакторить/перепроектировать ваше приложение. Это отстой, но так же много вещей. Но если Microsoft будет избегать всего, что не будет работать для ранее существовавших устаревших кодовых баз двадцатилетней давности, которые, вероятно, все еще включают COM-компоненты, написанные на VB 6.0, то еще через 20 лет ими станет Micro Focus.

@adamhathcock Это то, для чего я предполагал netstandard - подход к унификации, а не наименьший общий знаменатель. Он может двигаться так быстро, как хочет, но они будут обязательством, которое .NET framework в конечном итоге догонит. В конце концов появился бы сетевой стандарт, который в основном представлял собой .NET framework за вычетом специфичных для платформы вещей, а затем он был бы унифицирован.

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

Обновление .NET Framework — это принудительное обновление для каждой машины на планете, работающей под управлением Windows (в основном).

Обновление .NET Core — это обновление, которое вы выбираете для отдельного приложения .

Это очень разные звери.

Что ж, проще всего перестать ссылаться на эту страницу с самой первой страницы документации ASP.NET Core .

(Или просто добавьте строку «Не выбирайте .NET Framework, если вы хотите продолжать использовать ASP.NET Core!».)

они будут обязательством, которое .NET framework в конечном итоге догонит.

Есть https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

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

Но к тому времени, когда он наверстает упущенное, ASP.NET перейдет к следующей версии .NET Standard, и она никогда не будет подходящей версией .NET Framework для ASP.NET; оно всегда будет позади.

@markrendle нет, это не большой ком грязи. большой микс не означает, что они плохо спроектированы. они модульные. дело в том, что многие модули представляют собой проверенный в бою код, написанный давным-давно действительно умными людьми или купленный у третьих лиц. некоторые на c, некоторые на fortran, некоторые на c++/cli и т. д., чтобы перенести или переписать, нам нужно понять их, прочитать статьи, собрать больше реальных тестовых данных, повторно протестировать новую версию. это требует усилий, но такие задачи никогда не предусматриваются в бюджете, а зависят от нас самих. деловым людям все равно, используем мы ядро ​​.net или нет, но они хотят, чтобы функции были реализованы. а для третьей стороны мы должны призвать их или искать замену.
поэтому на практике это может занять несколько лет.

@бенаадамс

И вы можете использовать System.Web практически вечно; он встроен в Windows, что означает, что он, вероятно, никогда не исчезнет. Вы не получите много стабильного и надежного, чем это.

ASP.NET Core 1.x -> ASP.NET Core 2.x; все API практически одинаковы, главное изменение — отказ от поддержки .NET Framework. Он даже меняет семвер на перерыв 😱
ASP.NET Core 1.x работает на .NET Core 2.x и .NET Framework, поддерживает .NET Standard 2.x (через .NET Core 2.x); и имеет тот же API, что и ASP.NET Core 2.x, так что это стартовая версия.
ASP.NET Core 2.x — это выпуск перерыва. Он по-прежнему поддерживает .NET Standard 2.x (через .NET Core 2.x), и между ASP.NET Core 1.x и ASP.NET Core 2.x мало что изменилось с точки зрения API; но сбрасывает .NET Framework.

Да, и давайте посмотрим, каковы на самом деле варианты :) ASPNET Core 1.x — это тупик: вы можете портировать его, но ваш код не может перейти на ядро ​​.net, если вы зависите от библиотек, которые сегодня заполнены .net и может не быть перенесен на .net core/standard после прекращения поддержки. Выбор ASP.NET core 1.x сейчас разумен только в том случае, если ваши зависимости уже находятся на netstandard2.0/.netcore, тогда вы можете без проблем перейти на asp.net core 2.x, зная, что вы не заходите в тупик.

Ваше предложение выбрать system.web в качестве альтернативы nginx и стеку JVM, если вы хотите иметь стабильность, немного слабое, вам не кажется? :) Речь идет о вариантах для большой организации, что выбрать в качестве платформы. Если они не создают совершенно новое приложение, которое не должно работать с внешними зависимостями (редко), они, скорее всего, сделают безопасную ставку, а почему бы и нет? Если дело доходит до system.web или JVM/nginx, выбор довольно прост.

Это мелочи. Я забил на это раньше: функции шифрования предприятий sql server. Вы не собираетесь использовать их в ядре .net, поскольку их там нет. Оракул? Неа. Поэтому, если вы хотите использовать ядро ​​​​asp.net и эти функции, вы должны использовать .net full и asp.net core 1.x. Но что произойдет, если эти функции не будут перенесены/доступны после окончания поддержки asp.net core 1.x? (и кто хочет поставить ферму на платформу, которая уже находится в «режиме QFE»?) Вернуться к system.web?

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

Если что-то новое нужно добавить в версию .NET, то оно должно быть доступно для всех через сетевой стандарт Bump (с vNext), а затем ASP.NET обновляется, чтобы использовать его, когда оно будет выпущено. Я думаю, что эта проблема вызвана привилегированным положением ASP.NET. Это может быть неизбежно из-за того, что группы разработчиков внутри Microsoft одинаковы...

Как автор программного обеспечения для высокопроизводительных вычислений, активно использующего .NET, мы также внедрили собственный синтаксический анализ с нулевым выделением памяти и т. д. без внесения изменений в базовую платформу. Выиграем ли мы от Span и т. д.? Абсолютно! Можем ли мы перейти на .NET Core? Не надолго. Увидим ли мы, что Span и т. д. добавлены в .NET Framework? Кажется, сейчас трудно сказать, не будучи обязательством сетевого стандарта...

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

@markrendle я не уверен, кто является предполагаемыми пользователями ядра asp.net. но то, что я видел, это в основном пользователи .net, которые вложили большие средства в .net и большую устаревшую (неплохую) кодовую базу. если мы не предполагаемые пользователи, я не вижу, чтобы ребята из node.js/python/go ругали .net, независимо от того, насколько хорош, по нашему мнению, .net.
если это не для компании, а для моих собственных проектов, я не буду использовать asp, а вместо этого буду использовать nancy. компаниям нужна стабильная гарантия и поддержка. и они/мы платим за это большие деньги.

Простое решение этой проблемы было бы, если бы Microsoft сделала дистрибутив CoreCLR только для Windows, который поддерживает весь спектр библиотек .NET Framework.

Лично мне нравится играть с .NET Core на PI на Ubuntu, но деловая сторона даже не рассматривала .NET Core, потому что .NET Framework делает все, что нам нужно, а .NET Core — это только проблемы в сравнении. Большая часть этих проблем была связана с инструментами и настройкой всех, поэтому эти проблемы, наконец, ушли, но ему по-прежнему не хватает многих функций ... EF Core даже близко не достаточно мягкий, чтобы заменить EF6 или NHibernate, и они победили также не работает на .NET Core 2. Отсутствие WCF (хоста) для служб SOAP является довольно обременительным, поскольку именно этим мы занимаемся весь день в деловом общении, но, вероятно, его можно смягчить за счет продуманного дизайна и использования .NET Core и .NET Framework в нескольких приложениях. AppDomains также нелегко заменить, хотя это наименьшая из моих проблем. Переход от ASP.NET MVC 5 к MVC Core оказался неожиданно легким для перезаписи, но переход на .NET Core заставляет VS перестать взаимодействовать, отображая все ошибки.

Такие забавные вещи, как размещение ASP.NET Core внутри WPF, также будут невозможны.

Даже не имеет значения, будет ли дистрибутив Windows CoreCLR с закрытым исходным кодом, поскольку сегодня он мало чем отличается от .NET Framework.

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

Ваше предложение выбрать system.web в качестве альтернативы nginx и стеку JVM, если вы хотите иметь стабильность, немного слабое, вам не кажется?

Крайний конец ;)

Если дело доходит до system.web или JVM/nginx, выбор довольно прост.

Да, если вы можете перейти на JVM, вы используете ASP.NET Core 2, поскольку у вас нет блокировщиков, и у него хорошее взаимодействие и p/invoking :)

если API-интерфейсы «почти одинаковы», почему бы вам не оставить одну версию с 2-кратным номером для всех, но с возможностью выбора «netstandard» или «netcore»?

Потому что меняются внутренности; и использование изменений в среде выполнения, jit и стандартных библиотеках. Для пользователя они кажутся в основном такими же, как и совместимость между ASP.NET 1.x и 2.x; на открытой поверхности API, а не на внутренностях «вот как это делается».

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

Как и другие люди. Вы можете сделать запрос API на dotnet/corefx , как я сделал, например, для ValueTask ; который затем превратился в Task-like и теперь является частью C # 7.

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

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

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

Как автор программного обеспечения для высокопроизводительных вычислений, активно использующего .NET, мы также внедрили собственный синтаксический анализ с нулевым выделением памяти и т. д. без внесения изменений в базовую платформу. Выиграем ли мы от Span и т. д.? Абсолютно! Можем ли мы перейти на .NET Core? Не надолго.

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

Увидим ли мы, что Span и т. д. добавлены в .NET Framework?

да

@бенаадамс

Но к тому времени, когда он наверстает упущенное, ASP.NET перейдет к следующей версии .NET Standard, и она никогда не будет подходящей версией .NET Framework для ASP.NET; оно всегда будет позади.

Что совершенно нормально и приемлемо, если есть по крайней мере 1 перекрытие версий (т.е. если вы остаетесь на последней полной платформе, все еще существует по крайней мере одна официально поддерживаемая версия (ASP).NET Core).

Microsoft сделает дистрибутив CoreCLR только для Windows, который поддерживает весь спектр библиотек .NET Framework.

Или набор библиотек .NET Standard 2.0; чтобы они могли работать на .NET Core, которые работают только в Windows, которые покрывают пробел API?

@benaadams да, это идея, хотя это не сработает для всего, что выдает PlatformNotSupportedException

@qrli Если он модульный, то вы можете обновить модули, которые можно обновить сейчас, а остальные оставить на потом.

Если под «модульным» вы не имеете в виду «это массивное монолитное приложение System.Web ASP.NET IIS, включающее десятки различных библиотек, взаимодействующих через PInvoke и COM», в этом случае это большой ком грязи.

Есть ли окончательный список, какие сборки затронуты, а какие нет? Было упомянуто, что Microsoft.Extensions.* является безопасным, а Microsoft.AspNetCore.Razor.Runtime (предположительно) тоже, благодаря чему Microsoft.AspNetCore.Html.Abstractions также должен оставаться на netstandard . Есть ли что-нибудь еще в Microsoft.AspNetCore.* , что остается на netstandard ?

@bencyoung Мой рекомендуемый план перехода состоит в том, чтобы со временем перенести различные компоненты в автономные службы, ориентированные на .NET Core 2.x (или что-то еще, что лучше всего работает из всей вселенной инструментов разработки для этого конкретного компонента), используя эти службы из вашего устаревшего кода. стандартная граница API с использованием HTTP или шины сообщений, пока вы не получите правильную архитектуру распределенной системы.

@markrendle Однако не все принадлежит распределенной системе. В качестве конкретного примера: большая часть того, почему Stack Overflow так быстро отображает страницы, заключается в том, что он не распределен. Хотя наша сетевая задержка составляет 0,017 мс, это добавит нашему приложению немало затрат на сеть, сериализацию, десериализацию и сборку мусора. Разделение системы на множество сервисов — не универсальный ответ. Это сложный, дорогостоящий и чистый негатив для многих сценариев. Это может быть хорошо, но это также может быть слишком сложно и плохо.

@markrendle Моя проблема не в переходе на сервисы, а в том, что некоторые из основных строительных блоков сервисной инфраструктуры используют API, которых нет в дорожной карте для netstandard20 или даже netstandardbanana . .NET Core для нас — это не новые приложения, а целые новые системы. System.DirectoryServices — это один пример, но для других — это WCF и многие другие — это System.Data и материал SqlClient, а для нас — System.Messaging .

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

@NickCraver Я не хочу шутить или что-то в этом роде, и я знаю, что настоящая причина того, что страницы SO отображаются так быстро, заключается в том, что вы и другие люди, которые их создают, потрясающие, но результаты поиска Google, которые включают ссылки на ваши страницы отображаются так же быстро, как ваши страницы, и вы _знаете_, что они исходят из большой, сложной распределенной системы. Страницы Amazon отображаются довольно быстро, то же самое. Я с оптимизмом смотрю на то, что ASP.NET Core движется к будущему, в котором его можно будет использовать для создания систем так же, как они строятся, с той же производительностью, и я думаю, что у него будет больше шансов достичь этого, если он освободится от полный цикл обновления .NET, превращающийся в маленький остров.

@jbogard Я вижу подобное, но все будет совсем иначе, когда выйдет .NET Core 2.0.

Вздох.

@jbogard

нетстандартныйбанан

цитата из треда

Основная проблема для меня и моей команды в том, что не было никаких указаний на то, что этот путь был намеченным будущим. Я понимаю, что никто не знает будущего, но слышал, что нам нужно вырваться из всего, что полагается на полную структуру .net (библиотеки dll поставщиков компонентов, SDK платежных услуг, HSM sdks) в свои собственные службы и ввести этот новый переход STINGS. Это просто не то, что нужно этому сайту, и теперь нам нужно либо добавить больше сложности в разработку, либо переделать часть веб-приложения в MVC 5.

Мы выбрали ядро ​​​​asp.net из-за скорости пустельги и нового модного API. Было бы неплохо иметь возможность более точно сопоставить варианты с отсутствием простого пути обновления, учитывая наши зависимости.

Добавление в @jabrown85
До сих пор ASP.NET Core вызывал бурю эмоций.
После того, как csproj приземлился, я, наконец, сказал: «Теперь он готов» и решил, что не составит труда начать что-то новое в нем и проверить, что можно обновить. После этого объявления это больше похоже на: «Определенно ли .NET Core поддерживает этот сценарий или нам следует перестраховаться и просто остаться с MVC5?»

Потери пока невелики, только одно приложение, написанное на ASP.NET Core, управляет административными задачами основного приложения MVC 5, но оно застрянет на 1.x навсегда, потому что основное приложение использует NHibernate.

@markrendle компьютер говорит нет

Было бы неплохо, если бы была какая-то дорожная карта для полного .NET -> netstandard. Некоторые из основных частей просто говорят «Не поддерживается» от ApiPort. Я проведу более полный анализ клиентских проектов на ASP.NET Core 1.x, чтобы увидеть, чего не хватает.

но он навсегда застрянет на 1.x, потому что основное приложение использует NHibernate.

Не должно быть, NHibernate не умер, не так ли?

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

@benaadams официально нет, у него есть паузы, когда он кажется почти мертвым, но обычно есть одна фиксация каждые несколько дней. ApiPort сообщает о покрытии 72,26% для .NET Standard, но я не очень уверен, что он будет портирован (по крайней мере, в ближайшем будущем).

Читая комментарии, я обеспокоен общим направлением, в котором движется этот проект. Долгое время ASP.NET был хорошим выбором стабильной и надежной технологии. Однако сейчас я не испытываю того же чувства. Существует много технологий «двигайся быстро и ломай вещи», но это совсем другая категория.
Я надеюсь, что Microsoft сможет решить эти проблемы и оправдать все ожидания.

Речь идет не о корпоративном и не корпоративном программном обеспечении. Сегодня используется множество приложений Python 2.x, и не все из них являются «предпринимательскими». Более того, не все новые проекты используют Python 3 (почти 9 лет после выпуска Python 3.0!).

Кто-нибудь может обобщить всю ветку в блоге?

Я прочитал все 300+ комментариев по дороге на работу/обед и ... кажется, я до сих пор не «полностью понял».

Что я получаю:

• Полная версия .NET Framework не будет поддерживаться в .NET Core 2.
• Каждая зависимость будет зависеть от netcoreapp2.0 вместо netstandard2.0
• Если я хочу что-то вроде DirectoryServices или Drawing, мне нужно отказаться от Full Framework и перейти на 2.0.

Я немного пропустил остальное... плотный график и все такое.

@MaximRouiller

Если я хочу что-то вроде DirectoryServices или Drawing, мне нужно отказаться от Full Framework и перейти на 2.0.

Нет, если вам нужна библиотека, не поддерживающая ядро ​​.net, вы вообще не сможете использовать AspNet Core 2.0+.

@MaximRouiller , они только что сделали то, что основные проекты Asp.Net не смогут ссылаться на полные сборки фреймворка, что сделает его бесполезным для многих, если не для большинства, они говорят, что такие сборки, как system.drawing и Directoryservices, будут перенесены в новый сетевой стандарт. или я не знаю, тем не менее, старые сборки не будут работать, если кто-то их не портирует, поэтому для многих это практически бесполезно, потому что некоторые сборки являются устаревшими и никогда не будут портированы. В заключение, любой, кто использовал .net core с полной версией .NET framework, просто облажался и должен вернуться к MVC 5.

@davidfowl Кстати, спасибо за этот список . Это очень важно: «Итак, что мы получаем от этого?» часть, необходимая для людей, чтобы сбалансировать затраты/выгоды в их сознании.

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

@davidfowl , ты сказал:

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

Но почему это так? Разве вы не можете выпустить .NET Standard vNext, чтобы .NET догнал его через некоторое время (от нескольких месяцев до года)? Это означает, что люди, которые находятся на переднем крае и хотят использовать последнюю версию ASP.NET Core, могут размещаться в .NET Core, а люди, которым .NET нужен для их устаревшего кода, могут в конечном итоге использовать эту версию ASP.NET Core, как только .NET догонит ее. к версии .NET Standard, которую он использует. Я не понимаю, почему .NET Standard нужно обновлять так же быстро, как и самую низкую реализацию.
Также здесь речь идет об официальных реализациях стандарта, но будут и другие реализации, которые не будут обновляться в тандеме со стандартом.
Так вы не оставите людей позади. Конечно, им требуется немного больше времени, чтобы воспользоваться новейшими функциями, если они находятся в .NET, но они не застревают навсегда.

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

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

Если мы продолжим повышать нижний водяной знак для стандарта .net в ASP.NET Core, это лишает цели и оставляет вас в той же ситуации. Конечно, вы не чувствуете себя обделенными, потому что есть обещание, что когда-нибудь эти API появятся в .NET Framework, но в какие сроки? .NET 4.7 по-прежнему не полностью соответствует функциям .NET Standard 2.0.

@davidfowl, но это вернет ту же проблему, что и с PCL, он станет наименьшим общим знаменателем и болью в использовании, тот факт, что ASP.NET отказывается от его использования, уже показывает это.

@davidfowl, но это вернет ту же проблему, что и с PCL, это станет наименьшим общим знаменателем и болью в использовании,

@Suchiman , в чем проблема? Единственная проблема с PCL заключалась в том, как они динамически рассчитывались и представлялись в NuGet, из-за чего было трудно предсказать, что вы собираетесь получить. Как еще мог бы работать netstandard, если бы он не был набором API, который можно было бы реализовать с помощью различных реализаций?

Что раздражало в использовании PCL, так это супер-пупер малая поверхность API. .NET Standard 1.3-1.4 достаточно для реализации большинства базовых библиотек с точки зрения API.

.NET Standard всегда отличался широтой охвата.

ASP.NET Core и .NET Core представляли собой конкурентоспособный кроссплатформенный серверный стек для создания легковесных микросервисов. Дыханием в этом смысле стала более широкая поддержка платформ (работает на linux, osx, tizen, pi и т. д.).

@davidfowl

Мы определили строки как одну из основных вещей, которые мы хотели бы попробовать решить в .NET Core, есть множество идей, но одна из них — сделать строку по умолчанию utf8 (множество проблем с совместимостью, но следуйте за мной здесь).

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

Похоже, это означает, что если я хочу использовать эти новые биты в библиотеке, библиотека также должна быть нацелена на netcoreapp2.0 вместо netstandard2.0 . Это правильно?

Это действительно плохая идея — больше не поддерживать старый фреймворк 4.x. Люди не обновляются, если это требует много работы. См. Супер старый классический ASP, который устарел с 2002 года - около 15 лет. И у нас есть старые приложения, которые до сих пор существуют в классическом ASP! Microsoft хочет снова увидеть что-то подобное? Отказ от старой поддержки 4.x — это то, что должно быть сделано в обязательном порядке, но в долгосрочной перспективе! Не сейчас. Это может стать вариантом через несколько лет, когда ядро ​​.NET станет стандартом де-факто и только старые приложения будут использовать сеть 4.x.

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

@davidfowl

.NET Standard всегда отличался широтой охвата.

Широта в API или платформах?

В чем проблема с развитием .netstandard в том же темпе, что и .netcoreapp ?
Является ли какая-либо из настроек BCL специфичной для .netcoreapp , потому что они никогда не будут реализованы в других фреймворках?

Выпуск .netstandard2.1 одновременно с .netcoreapp2.1 не имеет значения, если сначала выпустить .netcoreapp2.1 , а через год .netstandard2.1 одновременно с .net50 , за исключением того, что пакеты, предназначенные для .netstandard2.1 , сразу же начнут работать на .net50 , но будут заблокированы, если они нацелены .netcoreapp2.1

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

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

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

Возможно, уменьшить масштаб ASP.NET Core 2.0, встроенный в .NET Standard 2.0, а затем использовать .NET Standard 2.1 для новых функций? Добавьте несколько приличных сроков поддержки, и разве это не решит всю эту дилемму? Microsoft владеет .NET Standard и обеими фреймворками, так что опасения по поводу увеличения версий кажутся совершенно необоснованными...

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

ASP.NET на полном фреймворке останется и получит новые функции, но не такие, как Core.

Миграция со временем станет проще, но никогда не будет соответствовать 100%.

Люди до сих пор используют классический ASP. Для них это тоже хорошо.

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

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

• Мы определили строки как одну из основных вещей, которые мы хотели бы попробовать решить в .NET Core, есть множество идей, но одна из них — сделать строку по умолчанию utf8 (множество проблем с совместимостью, но следуйте за мной здесь).

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

• Еще одна вещь, которую мы хотели бы исправить, — это возможность брать дешевые фрагменты массивов/строк, любую часть непрерывной памяти. Мы добавили диапазони смотрим на буферпредставлять это. Это может означать, что String и Array реализуют новые интерфейсы, которые позволяют использовать срез, требующий нулевого распределения.
• Это приводит к новым методам для String, которые позволяют выполнять разбиение без выделения массива каждый раз.
• Это приводит к перегрузкам Int, UInt и т. д. (TryParse), которые занимают Spanи диапазон.
• Это приводит к новым процедурам кодирования, которые берут Span.
• Буфери диапазонпозволяет вам представлять память единым образом, и мы хотим обновить сетевой стек, чтобы разрешить передачу предварительно закрепленных буферов, которые занимают Spanили буфер.

Все это по-прежнему можно реализовать в виде пакетов поверх текущего сетевого стандарта. Для этого вам даже не нужен netstandard20. Я понимаю, что не хочу носить с собой этот багаж, но остальным из нас в мире, отличном от MS, приходится все время создавать собственные реализации в стиле BCL, когда вариант использования или производительность не подходят. Не говоря уже о том, что Span API также не предназначен для 2.0 (если это снова не изменилось).

Kestrel реализует HTTP2 в период времени 2.x (в настоящее время нацелен на 2.1), и для этого требуются новые API в потоке SSL для выполнения ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http-клиент на .NET Core поддерживает дуплексную потоковую передачу, что позволит реализовать конечные точки потоковой передачи через http в signalr с помощью одного http-запроса без веб-сокета.

Я чувствую, что этот немного сложнее, но не сильно отличается от пустельги, таскающей либув. Реализация CURL из .Net Core может быть легко включена в пакет расширения netstandard, пока все не наверстают упущенное.

• Мы разветвили реализации парсера заголовков из HttpClient и System.Net.Http и переименовали их (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers), чтобы мы могли их улучшить. и пусть они поддерживают как .NET Framework, так и .NET Core. В .NET Core есть копия этих улучшений, которая не вернулась, потому что в них нет необходимости (мы не могли их использовать).

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

• Не имея возможности переработать базовые примитивы, нам предлагается разветвлять их и создавать вещи, которые выглядят как они, но ими не являются. Именно поэтому у нас есть собственный небольшой BCL в ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Опять же, как и все мы.

ASP.NET Core и .NET Core представляли собой конкурентоспособный кроссплатформенный серверный стек для создания облегченных микросервисов.

У ASP.Net Core был такой обмен сообщениями. .Net Core с самого первого дня позиционировался как полностью функциональное подмножество xplat на стороне сервера .Net framework. Я никогда не слышал, чтобы кто-то говорил, что .Net Core предназначен только для микросервисов. Я слышал, что вы можете использовать его с ASP.Net Core, если хотите, а также с консольными приложениями, анализом данных, службами БД и т. д. Является ли направление .Net Core эффективным «всем, чего больше всего хочет команда ASP.Net Core»?

ASP.NET на полном фреймворке останется и получит новые функции, но не такие, как Core.

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

Предполагая, что у нас есть сборка бизнес-логики 4.6, которая использует драйвер Oracle.Net, NHibernate и RabbitMQ (все они в 4.6). Интерфейс с ASP.Net осуществляется только через наши бизнес-объекты, запросы и ответы. Можем ли мы сослаться на эту сборку в нашем ASP.Net Core 2 без перекомпиляции?

Мое краткое резюме

@stefan2410 краткий ответ: нет, вы не можете ссылаться на полный фреймворк, вы можете ссылаться на эти сборки, только если они созданы для netstandar 2.0.

@mattnischan

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

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

Не говоря уже о том, что Span API также не предназначен для 2.0 (если это снова не изменилось).

Span существует в версии 2.0 как реализация, но не как общедоступный API. Мы вносим критические изменения в новые основные версии, чтобы иметь больше возможностей в дополнительных версиях. Если ASP.NET Core 2.1 нацелен на .NET Standard 2.1, то поддержка .NET Framework снова прекращается.

Я чувствую, что этот немного сложнее, но не сильно отличается от пустельги, таскающей либув. Реализация CURL из .Net Core может быть легко включена в пакет расширения netstandard, пока все не наверстают упущенное.

Итак, вы говорите, что мы должны переименовать все классы в BCL, чтобы мы могли использовать их как в .NET Standard.

Я никогда не слышал, чтобы кто-то говорил, что .Net Core предназначен только для микросервисов. Я слышал, что вы можете использовать его с ASP.Net Core, если хотите, а также с консольными приложениями, анализом данных, службами БД и т. д. Является ли направление .Net Core эффективным «всем, чего больше всего хочет команда ASP.Net Core»?

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

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

Да, поддержка HTTP/2 была добавлена ​​в последнем релизе. Есть еще одна команда, которая работает над ASP.NET и IIS и вносит улучшения. Однако они не в том же масштабе, что и ASP.NET Core.

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

Я опасаюсь, что устранение возможности запуска ASP.NET Core на полной платформе оттолкнет пользователей от переноса их текущих приложений MVC 5/Web API 2 на ASP.NET Core, что просто предоставит авторам библиотек еще одну причину избегать переноса на .NET. Стандарт. Зачем беспокоиться об обновлении, если ни один из ваших пользователей не получит от этого пользы? Это становится проблемой курицы и яйца, и я просто боюсь, что это повредит экосистеме в целом, как только она начала набирать обороты. Во-первых, вам нужны пользователи ASP.NET Core, и я не уверен, что их так много, как нам всем хотелось бы. Надеюсь, я ошибаюсь.

Если ASP.NET Core 2.1 нацелен на .NET Standard 2.1, то поддержка .NET Framework снова прекращается.

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

То же самое для всех других платформ, совместимых с .NET Standard (Xamarin/Unity/...).

Использование .NET Standard означает, что другие платформы _в конце концов_ загорятся, а создание .NET Core означает, что они загорятся __никогда__.

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

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

Последнее — это то, что уже сделано в большинстве случаев в 1.x, верно? Это вдруг перестало быть приемлемым?

Span существует в версии 2.0 как реализация, но не как общедоступный API. Мы вносим критические изменения в новые основные версии, чтобы иметь больше возможностей в дополнительных версиях. Если ASP.NET Core 2.1 нацелен на .NET Standard 2.1, то поддержка .NET Framework снова прекращается.

Почему это было бы брошено? Вы говорите, что Span _никогда_ не будет существовать в Framework?

Итак, вы говорите, что мы должны переименовать все классы в BCL, чтобы мы могли использовать их как в .NET Standard.

Вау, нет. Я говорю, что если мне нужен словарь с другим API, я должен создать что-то еще, а также не называть его System.Collections.Generic.Dictionary, как вы, ребята, уже сделали с Microsoft.Net.*

Да, поддержка HTTP/2 была добавлена ​​в последнем релизе. Есть еще одна команда, которая работает над ASP.NET и IIS и вносит улучшения. Однако они не в том же масштабе, что и ASP.NET Core.

Это честно. Я не знал об этом.

Последнее — это то, что уже сделано в большинстве случаев в 1.x, верно? Это вдруг перестало быть приемлемым?

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

Почему это было бы брошено? Вы говорите, что Span никогда не будет существовать на Framework?

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

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

Насколько мне известно, Spans являются частью пакета netstandard1.x , который можно использовать на .NET Desktop (это переносимая реализация, поэтому она не имеет такого же повышения производительности, как если бы она была сохранена в CLR, но, вероятно, достаточно хорошо).

Изменить: пакет System.Memory имеет TFM netstandard1.0 , поэтому его можно использовать даже в .NET 4.5.

Последнее — это то, что уже сделано в большинстве случаев в 1.x, верно? Это вдруг перестало быть приемлемым?

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

Почему это было бы брошено? Вы говорите, что Span никогда не будет существовать на Framework?

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

Вау, нет. Я говорю, что если мне нужен словарь с другим API, я должен создать что-то еще, а также не называть его System.Collections.Generic.Dictionary, как вы, ребята, уже сделали с Microsoft.Net.*

Это именно то, что вы предлагаете. Мы не хотим иметь Microsoft.Extensions.Collections.Generic. Мы изо всех сил пытаемся избежать этого и по возможности используем старые API и полифиллы (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). Это не является устойчивым, и это означает, что .NET Core не получает преимуществ, потому что мы активно избегаем его использования.

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

@0x53A

Это честно. Можете ли вы сказать мне, почему популярные библиотеки в NuGet не отказываются от поддержки более старых версий .NET Framework, которые явно не поддерживаются? Самые популярные библиотеки ориентированы на net20, net35, net40 и т. д. Почему вдруг может потребоваться самая высокая версия .NET Framework, чтобы продолжать использовать ASP.NET Core? Как вы думаете, это было бы разумно?

Это шоу-стоппер. Я должен рассмотреть возможность отмены миграции с ASP.NET MVC 5/Web Api 2 на ядро. Многие стабильные фреймворки еще не доступны для ядра. Мы по-прежнему используем EF6.x, потому что EF Core недостаточно проработан. Сравнение функций .

@PinpointTownes , имеющие диапазоны, недостаточно хороши, им нужно использовать их в вызовах методов для существующих типов.

«нужно», вероятно, немного чрезмерно. Spans в основном используются для повышения производительности, поэтому ничто не мешает им использовать существующие перегрузки not-super-perfy в .NET Desktop с помощью ifdefs, пока .NET Desktop не получит встроенную поддержку Spans.

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

Но некоторые приложения никогда не смогут совершить прыжок netfx -> netcore, поэтому, если вы нацелитесь на netcore, они знают, что с 1.x находятся в тупике.

В этом отношении было бы лучше, если бы ядро ​​Asp.net никогда не работало на netfx в его нынешнем виде, они ожидали, что это продолжится, и теперь чувствуют себя (по праву, ИМО) преданными. В конце концов, они, возможно, уже вложили в это много времени.

Я лично не инвестирую в это, потому что я не пользователь asp.net, мой большой вопрос на самом деле просто

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

Что касается других библиотек, ориентированных на net20, net35 и т. д., по моему опыту, большинство авторов стараются ориентироваться на самую низкую версию, которую они могут, и урезают платформы только там, где у них нет другого выбора.

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

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

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

@davidfowl Я думаю, что это, возможно, часть проблемы. Честно говоря, я немного играл здесь адвоката дьявола, потому что мы застряли посередине как новое приложение, которое началось как раз перед тем, как .Net Core стал чем-то особенным, поэтому мы балансируем между линиями.

Мы всегда думали так: используйте новые модные библиотеки (такие как Kestrel), если это вообще возможно, но подождите, пока .Net Core стабилизируется (и я рад, что мы это сделали, хотя бы для изменений инструментов), _или_ подождите, пока крутые биты Core, чтобы вернуться к Framework. Я думаю, что большинство людей предполагали, что большинство, если не все, усовершенствований, сделанных corefx, воплотятся в Framework vNext или vNext+1. Но, судя по этим и другим изменениям (с нашего обзора с высоты 30 000 футов), кажется, что Framework не является платформой будущего.

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

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

Не может быть и того, и другого: либо полная обратная передача на .NET в порядке, они просто выпускают реже (например, каждые 6 месяцев до года), либо это очень сложно и подвержено ошибкам. Если это первое, просто увеличьте темп и не позволяйте своим пользователям оплачивать счета и перестаньте использовать последнее в качестве оправдания. Если это последнее, то не является ли правильным вывод, что netstandard является ошибкой, поскольку в любом случае все, что имеет значение для будущего , - это API .netcore?

Меня серьезно беспокоит будущее направления .NET. Моя компания создает инструменты для .NET full и .NET Standard1.6. Последнее, чего мы хотим, — это чтобы движущая сила направления .NET (новые функции, которые скоро будут полностью перенесены в .NET, как сказано в анонсе ядра .NET много месяцев назад) эффективно разделяла вещи и экосистему. делится пополам, так как фрагментация убивает.

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

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

Эти двое не совпадают на данный момент. Может кто-нибудь из Microsoft, пожалуйста, расскажите последовательную историю, чтобы мы все могли увидеть, что на самом деле происходит, как обстоят дела на самом деле, то есть с переносом функций в .net full, что сделано с отсутствующим множеством вещей в .net core. (вещи sqlserver, объем транзакций и многое другое) и как Microsoft думает, что они могут продавать это новое направление как надежную, надежную платформу для будущего, чтобы корпорации и большие команды могли выбирать ее, не беспокоясь.

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

Мы хотели бы перейти на .NET Core как можно скорее, но, к сожалению, сейчас наши самые большие препятствия — это почти исключительно библиотеки Microsoft (например, Entity Framework Core еще недостаточно хорош, служебная шина Azure имеет только очень раннюю предварительную версию).

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

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

«Просто оставаться на 1.x» не кажется хорошей альтернативой, потому что наверняка будет много библиотек, которым все равно (или у которых нет ресурсов/знаний для поддержки обоих), и они просто обновят свою зависимость до 2.0

PS: я очень разочарован тем, насколько сложной стала экосистема .NET за последние несколько лет. Мне пришлось потратить МНОГО времени, чтобы понять все новые вещи, и я не понимаю, как новый разработчик должен понимать что-либо из этого. Сейчас в Интернете очень много устаревшей информации из-за всех этих довольно радикальных изменений.
Кроме того, все разные версии продукта (ядро .net, SDK, стандарт .net, ...) чрезвычайно запутаны. Я еще не видел кого-то, кто понимает стандартную таблицу .NET, не нуждаясь в 20-минутном объяснении. 😞

любой, кто использовал .net core с полной версией .NET framework, просто облажался и должен вернуться к MVC 5

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

У нас есть экосистема приложений, как и у многих других, с общими библиотеками, созданными более десяти лет назад, несколькими приложениями MVC 3, 4, 5, консольными приложениями, службами Windows, сотнями тысяч строк кода. Мы даже не в такой плохой ситуации, чтобы обновляться по сравнению с некоторыми.

Недавно мы запустили пару новых веб-приложений, использующих ASP.Net Core 1.1, обязательно ориентированных на полную платформу 4.6.2. Эти приложения используют большую часть наших существующих общих библиотек. Мы потратили уйму времени разработчиков на работу с project.json, затем на новый .csproj, пытаясь смешать старые и новые .csproj в одном решении, вернуться к VS15, чтобы сделать что-то со старыми типами .csproj, сломанными Система. зависимостями и целым рядом проблем с привязкой сборки, проблем со сборкой и публикацией... список можно продолжать и продолжать.

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

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

Да, и, конечно же, библиотеки Azure Service Fabric также не работают на ядре .NET, что является еще одним препятствием для нас.

Я бы сказал, что вы должны поддерживать полную инфраструктуру .NET до тех пор, пока не сможете создать правильную историю ядра .NET в Microsoft (и особенно в Azure).

@cwe1ss Это изменение несколько уменьшит сложность экосистемы .NET. Так как у вас не будет двух разных форматов (ASP.NET Core + .NET Full и ASP.NET + .NET Core). Я полностью согласен с устаревшей информацией, но я думаю, что этого нельзя избежать, когда вы разрабатываете на открытом воздухе, как это делает Microsoft сейчас.

@davidfowl

История совместного использования кода в разных средах выполнения .NET — это .NET Standard. Ваши библиотеки должны попытаться нацелить это на код, совместно используемый в .NET Core и .NET Framework.<

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

Microsoft, похоже, забыла о важности обратной совместимости.<<

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

Установка исправлений безопасности — это только часть проблемы. Веб-стандарты меняются так быстро, что нам нужно что-то, с чем мы могли бы использовать последние стандарты. Так, например, я где-то выше видел что-то про HTTPS v2. Я понятия не имею, что это означает на практике, но дело в том, что я хочу, чтобы мой фреймворк мог поддерживать эти вещи. Если мне придется остаться с более старой версией фреймворка, будь то v4 или v1, она не будет поддерживать то, что требуется.

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

Стефан

@Rutix для «открытой разработки» это серьезное критическое изменение было сделано на удивление тихо, без какого-либо объявления или опроса (в конце концов, эта проблема была создана членом сообщества, наблюдающим за запросами на включение).

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

Последний инцидент был https://github.com/dotnet/roslyn/issues/17054 , но они быстро исправили его, мне интересно, как это пройдет.

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

@stefanolson Это неправильно. Библиотеки, ориентированные на .Net Standard 1.x, сегодня могут работать на различных версиях полной платформы. Библиотеки, ориентированные на .Net Standard 2.0, должны работать на 4.6.1 в последний раз, когда я смотрел.

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

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

@stefanolson Так и есть. Различные (существующие) версии .NET Framework реализуют разные версии стандарта .NET. См. https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduction-net-standard/ .

Я знаю, что немного опоздал к этой теме, но вот два наших варианта использования ASP.NET Core на NetFX в Windows:

Использование ASP.NET для размещения REST API для вашего приложения

Наше приложение представляет собой приложение типа «.NET API, превращенное в REST API». Сначала он поставлялся как .NET API и имеет зависимости от всех видов Windows.

Когда мы добавили REST API, мы выбрали ASP.NET Web API для его размещения. Когда стало ясно, что веб-API унифицируется в ASP.NET vNext/5/Core, __and__ мы поняли, что __ASP.NET Core будет работать на NetFX__, имело смысл использовать ASP.NET vNext/5/Core.

Хотя мы используем преимущества .NET Core для переноса (части) нашего приложения на Linux и macOS, по-прежнему существуют зависимости от Windows, которые не работают на .NET Core (чтобы получить список зависимостей, которые мы перенесли, см. пакеты NuGet CoreCompat.* ).

Короче говоря, теперь мы заблокированы на ASP.NET Core 1.x, который будет поддерживаться в течение ограниченного периода времени. И что потом? Вернуться к ASP.NET 4?

Я понимаю всю работу, которую вы выполняете, и раздвигаете границы в других областях .NET Core, но в моем случае я не размещаю веб-сайт большого объема, доступный в Интернете, я размещаю REST API, который будет получить как что, 10-20 RPS максимум?

Поддержка Visual Studio

Действительно, мой опыт работы с Visual Studio 2017 в NET 4.x по-прежнему намного лучше, чем в .NET Core — хорошим примером является время, необходимое для повторной компиляции тестового проекта и появления новых тестов в тестовом окне. . На NetFX это намного быстрее.

В итоге мы оказались в ситуации, когда сегодня у нас есть проекты NetFX и .NET Core, компилирующие по сути одну и ту же кодовую базу. Единственная причина, по которой мы продолжаем это двойное обслуживание, заключается в производительности Visual Studio с проектами .NET Core (особенно_ модульные тесты и отладчик).

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

@mattnischan

@stefanolson Это неправильно. Библиотеки, ориентированные на .Net Standard 1.x, сегодня могут работать на различных версиях полной платформы. Библиотеки, ориентированные на .Net Standard 2.0, должны работать на 4.6.1, как я недавно смотрел.<

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

Было бы совершенно разумно, если бы для ядра asp.net требовался стандарт .net 2.1, потому что есть вещи, которые им нужны, но на данный момент не во фреймворке. Поэтому нам пришлось ждать, пока полная платформа .net не поддержит эти дополнительные функции, прежде чем мы сможем использовать последнюю версию ядра Asp.net. Это будет работать и иметь смысл.

Но вместо этого они просто отказываются от стандарта, делая стандарт бесполезным (если я правильно понимаю эту запутанную ситуацию)

Итак... сборка 2017 начинается завтра; Думаю, команда очень занята подготовкой к нему. Может какие-то объявления, может нет. Может быть, дать им немного передышки и собраться снова через неделю?

Может быть, поймать шоу https://build.microsoft.com/ (среда 8:00 по тихоокеанскому времени, 15:00 по Гринвичу и четверг аналогично?)

Мы можем знать больше; может нет. Что-то может стать яснее, а может и нет. Однако команда ASP.NET, скорее всего, сможет реагировать немного лучше и уделять больше внимания проблемам каждого. Хотя @davidfowl молодец !

@stefanolson Но вместо этого они просто отказываются от стандарта, делая его бесполезным (если я правильно понимаю эту запутанную ситуацию)

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

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

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

Прочитав эту тему, я чувствую:
.NET Core -> .NET Framework похож на ASP.NET MVC -> WebForms.

Я также хотел бы отметить инструментальный аспект. Текущая производительность восстановления/сборки/тестирования и т. д. очень плохая и мучительная. Если бы нам пришлось «оставаться на 1.0», смогли бы мы по-прежнему использовать более новые SDK с (надеюсь) более высокой производительностью или мы застряли бы с SDK 1.x?

История .NET Core — это замечательный тур, полный взлетов и падений. Мы только недавно начали работать над ASP.NET Core из-за всех предыдущих «неудачников» (версионирование, именование, переход между project.json и .csproj), и я с нетерпением ждал (и с нетерпением жду) .netstandard 2.0, потому что я думаю, это будет первый "настоящий" релиз.

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

Если вы хотите узнать, что является блокировщиком (помимо служб каталогов) с нашей стороны: мы все еще используем EF6 и все еще ждем официального пакета Open XML SDK NuGet, нацеленного на netstandardwhatever.
Миграция кода может занять очень много времени...

Можно ли формализовать какой-то процесс продвижения вперед netstandardXX на основе изменений, которые происходят в Core, что включает в себя нацеливание на него как часть этапа обслуживания выпуска библиотеки Asp.Net Core?

В нынешнем виде у меня есть приложение WebForms/MVC, которое мы собирались активировать при раскрытии веб-API ANC и вызове из SPA (и, в конечном счете, из устаревшего приложения WebForms), но мы не можем разработать CoreCLR из-за зависимость от драйвера Sybase (теперь SAP) Ase ADO.NET (если кто-то, читающий это, может нажать кнопку где-нибудь в SAP ... К сожалению, я вообще не слышу об этом или об ошибках, о которых я знал более уже 9 лет).

Читая этот выпуск, я больше не уверен, каким должен быть мой путь. Единственное, в чем я уверен, я могу планировать, так это в том, что драйвер с ошибками будет продолжать существовать для среды рабочего стола. Должен ли я был игнорировать изменения в ASP.NET за последние несколько лет, потому что они будут пустой тратой моего времени, и я должен просто ориентироваться на WebApi2? Должен ли я говорить о переходе на ANC 1.x, зная, что я, скорее всего, никогда не буду мигрировать и не увижу преимущества 2.x в приложении, которое, как я полагаю, будет поддерживаться здесь в течение следующих 10-15 лет (приложение WebForms имеет был перенесен и поддерживается с момента выпуска фреймворка 1.1)?

@davidfowl

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

Чего ждать?

Не все из нас веб-разработчики. Мы с нетерпением ждали лучшей поддержки обработки строк в течение многих лет, и теперь вдруг вы говорите нам, что мы SOL? Что .NET Framework и бесчисленное множество не-веб-приложений, построенных на его основе, никогда не получат доступ к библиотекам обработки строк на основе Span?

Это уже не просто проблема ASP.NET. Это лежит в основе долгосрочной приверженности Microsoft .NET Framework и ее библиотеке базовых классов.

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

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

жду с нетерпением официального анонса

Если я правильно понял, net coreapp 2.0 предоставит прокладку совместимости, которая позволит нашим проектам ASP.NET Core 2.0 зависеть от наших устаревших библиотек классов NetFx (например, net461).
Где я могу найти дополнительную информацию о планируемых в настоящее время возможностях/ограничениях такой совместимости?

@dgaspar Это не совсем точно, вот как это работает: netcoreapp2.0 поддерживает большинство API в net461 . Если ваша библиотека построена для net461 и вызывает только те API, которые существуют в подмножестве, которое поддерживает netcoreapp2.0 , вы все равно можете импортировать библиотеку (считайте это переопределением, которое вы знаете лучше) и заставить его работать, так как все классы и методы, которые он вызывает, должны быть там.

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

@NickCraver кто-нибудь помнит...

"imports": [ "dnxcore50", "portable-net45+win8" ]

Соответствующий комментарий я сделал в декабре. 11 больших пальцев перенесены вперед:

Что-то тут не так. Я выпускаю приложения на C# уже 15 лет. По иронии судьбы, по мере того, как Microsoft поставляет абстракции более высокого уровня, я трачу все больше и больше времени на глубокое копание во внутренностях, о которых раньше мне никогда не приходилось беспокоиться. ТЫ ДЕЛАЕШЬ ЭТО НЕПРАВИЛЬНО.

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

даже node.js позволяет нам легко вызывать все библиотеки netfx.

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

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

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

@qmfrederik

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

Далее мы делаем поддержку HTTP2, и для этого требуются новые API.

Я также хотел бы отметить инструментальный аспект. Текущая производительность восстановления/сборки/тестирования и т. д. очень плохая и мучительная. Если бы нам пришлось «оставаться на 1.0», смогли бы мы по-прежнему использовать более новые SDK с (надеюсь) более высокой производительностью или мы застряли бы с SDK 1.x?

Да, это сработает.

@davidfowl

Далее мы делаем поддержку HTTP2, и для этого требуются новые API.<

То есть поддержка HTTP2, которая будет доступна в asp.net core 2.0, не будет доступна в 1.x? Это действительно та проблема, о которой я беспокоюсь, когда у нас не будет доступа к новейшим технологиям, потому что мы по какой-то причине привязаны к полной инфраструктуре .net. Как я уже сказал выше, не имеет значения, потребуется ли от шести месяцев до года, чтобы этот фильтр дошел до того, что я использую, но в конечном итоге я не хочу слишком сильно отставать. Из-за совместного использования кода и использования сторонних библиотек на данном этапе мне нужна полная платформа .net.

наконец, я уточняю несколько вещей:

• когда я говорю устаревшие модули, это dll, зависящие от dll netfx или c++/cli, которые, в свою очередь, могут вызывать некоторые родные dll. они для бизнеса/алгоритма, без COM, без asp.net. они не плохие. они становятся устаревшими в основном потому, что ядро ​​.net их не запускает.
• в долгосрочной перспективе можно перейти на net core, и мы действительно этого хотим. но это действительно трудно сделать, чтобы это произошло. Нам и третьим сторонам потребуется несколько лет, чтобы быть там.
• библиотеки, специфичные для предметной области, намного медленнее, чем основные библиотеки для изменений технического стека. мы все знаем пример Python 3. эти специфичные для предметной области библиотеки являются реальным бизнесом.

@danielcrabtree

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

Это фантастика. Проблема заключается в том, как работать с существующими кодовыми базами и как сделать их пригодными для использования с ядром .net. Если бы WPF был доступен на основе ядра .net, я мог бы использовать ядро ​​.net везде. Но поскольку это не так, и мой код используется совместно WPF и ASP.net, мне нужен способ их совместного использования. Но я не хочу слишком сильно отставать от новейших веб-технологий и методов безопасности, большинство (все?) из которых, похоже, будут только в 2.x и более поздних версиях.

Несколько раз в этой ветке и в другой документации .NET Core описывается как кроссплатформенный. Это рекламировалось как один из основных аргументов в пользу перехода на платформу.

Однако, как выяснилось в этом разговоре в Твиттере, это не так.

https://twitter.com/James_M_South/status/861595907782987776

И комментарий выше; акцент мой.

Остальные большие пробелы, отсутствующие в .NET Core 2, — это System.DirectoryServices и System.Drawing. Мы работаем над созданием пакета совместимости для Windows, который этим летом позволит использовать обе версии .NET Core в Windows .

Я очень усердно работал с .NET Core с самого начала, пытаясь заполнить пробел, оставленный System.Drawing с помощью ImageSharp , и теперь я очень смущен и более чем немного недоволен и спрашиваю:

Что такое .NET Core сейчас?

Вот описание из MS Docs .

.NET Core — это платформа разработки общего назначения, поддерживаемая Microsoft и сообществом .NET на GitHub. Он кроссплатформенный, поддерживает Windows, macOS и Linux и может использоваться в сценариях устройств, облака и встроенных устройств/IoT.

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

Каждое описание, которое я читал, кажется другим.

Мы можем:

1. Пожалуйста, запишите где-нибудь достойное, последовательное сообщение, чтобы у нас действительно была цель, к которой нужно стремиться, и лучшее общее понимание.
2. Получите некоторую ясность в фактической дорожной карте для System.DirectoryServices и System.Drawing

System.Drawing , в частности, сбивает с толку и беспокоит. Я не могу понять, почему вы когда-либо хотели портировать этот API на .NET Core на любой платформе. С ним сложно работать, он не поддерживается на сервере и не имеет многих важных функций, необходимых для современной разработки (многопоточность, пиксельные форматы, ICC, EXIF, квантование, индексированный Png и т. д.).

Здесь много узнаваемых имен и лиц, и я знаю, что просто добавляю шума, но:

• DirectoryServices
• Рисунок (не то чтобы мне это нужно)
• ЭФ

Кажется, это три наиболее важные вещи, которые нужно успеть сделать до такого большого перерыва. Лично почти все, над чем я работаю, находится на net4x исключительно из-за EF6, так как EFCore... ну... :trollface:

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

@JimBobSquarePants
Я не думаю, что пакет совместимости Windows является частью .NET Core. Это специфичная для Windows библиотека, расположенная поверх .NET Core. Вы можете себе представить, что существует специальная библиотека для Linux, которая раскрывает функции только для Linux.

Я думаю, что пакет совместимости Windows предназначен для упрощения миграции существующих баз кода .NET Framework. Очевидно, что после того, как кто-то перешел на .NET Core, ему следует подумать о переходе на более совершенные решения, такие как ImageSharp.

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

Эта проблема GitHub была упомянута на немецком новостном сайте ИТ:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraerert-net-entwickler-mit-support-entscheidung-1705-127712.html

Спасибо @danielcrabtree , я впервые слышу о пакетах совместимости.

Перевод ссылки @MJomaa : https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraerert- net-entwickler-mit-support-entscheidung-1705-127712.htm

Я жду переноса System.Xaml.

@alexwiese не задерживайте дыхание.

Я жду переноса System.Xaml.

Продолжать; Я укушу. Как вы используете Xaml на своем веб-сайте?

Продолжать; Я укушу. Как вы используете Xmal на своем веб-сайте?

Кроссплатформенный пользовательский интерфейс (шаблоны экрана, совместно используемые консольным приложением с «зеленым экраном», приложением Xamarin и Angular SPA), также используемый для механизма бизнес-правил.

Ничего себе, хорошо, значит, вы каким-то образом преобразуете XML XAML в HTML и Javascript? Достаточно честно 😄

Не был уверен, что вы просто троллите.

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

Ничего себе, хорошо, значит, вы каким-то образом преобразуете XML XAML в HTML и Javascript? Достаточно честно 😄

Конечно, нет; Я сначала конвертирую в JSON 😉

Еще одна новостная статья на эту тему, многие из нас цитируются: https://www.infoq.com/news/2017/05/ASPNET-Core-2 .

@cwe1ss Автор @Grauenwolf

@alexwiese @yaakov-h Я бы хотел прочитать об этом в блоге; звучит довольно интересно и должно сопровождаться другим набором задач, чем я привык.

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

С этим изменением это прыжок «все или ничего». А учитывая, что вы не всегда понимаете все зависимости заранее, это увеличивает риск.

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

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

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

@davidfowl Как насчет чего-то вроде edge.js для сетевого ядра? Это делает потребителя API ответственным за проверки платформы, а строго типизированный интерфейс между netfx и netcore достаточен для большинства сценариев.

Будет ли этот шаблон удален после этого?

На данный момент он встроен в VS2017.

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

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

Этот комментарий о «полном охвате», который потенциально никогда не попадет в .NET Framework, серьезно беспокоит меня. Если full Span не входит в .NET Framework, то я предполагаю, что API, использующие его, никогда не смогут стать будущим сетевым стандартом, что делает невозможным написание кросс-платформенных библиотек, которые используют или предоставляют высокопроизводительный синтаксический анализ? Это означает, что мы навсегда застряли с нашими небезопасными пользовательскими реализациями...

Вы упомянули, что если вы хотите, чтобы ваша библиотека была кроссплатформенной, вам следует ориентироваться на сетевой стандарт, но что такое ASP.NET Core, если не широко используемая библиотека? Вы бы порекомендовали другим библиотекам отказаться от поддержки netstandard и перейти на .NET Core? Должна ли следующая основная версия JSON.NET или что-то еще отказаться от netstandard? Это, безусловно, может быть связано с быстрым разбором!

Примечание. Java удалось добавить быстрый ввод-вывод с нулевым копированием и т. д. обратно совместимым способом с Netty (https://netty.io/).

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

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

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

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

@JimBobSquarePants Я поддерживаю вас в части System.Drawing . В других репозиториях ведутся дискуссии о возвращении System.Drawing . Основываясь на некоторых комментариях в этой ветке, я понимаю, что сначала будет «пакет совместимости» для Windows, а затем для всех ОС за System.Drawing .

Интересно, как это будет выглядеть, и будет ли оно основано на libgdiplus от Mono или нет (что устранит некоторые проблемы с System.Drawing, но это уже другая история)

Хорошо, как я это вижу, на карту поставлено несколько вопросов:

1. Об этом сообщалось довольно плохо.
2. Люди не участвовали в принятии решения. Обратите внимание, что Microsoft, конечно, вольна выбирать направление, которое им нравится, но не обсуждать этот тип крупных изменений с сообществом — это не в духе разработки с открытым исходным кодом.
3. Не существует «большой схемы», которую сообщество могло бы использовать для проверки таких решений. Сначала .NET Core представлял собой урезанную кроссплатформенную версию полной платформы. Затем, с выходом .NET Standard 2.0, многим показалось, что .NET Core 2 будет чем-то вроде простой замены полной инфраструктуры, конечно, в разумных пределах (без UWP, WinForms и т. д.).
4. В .NET Core 2 будут упущены несколько важных функций, которые есть в полной инфраструктуре, например System.DirectoryServices. Насколько я могу судить, это было признано, но, возможно, путь к добавлению этих функций в .NET Core можно было бы сделать более явным.
5. ASP.NET Core 2 не будет работать на полной платформе из-за того, что в ней отсутствуют новые функции. Я на самом деле полностью согласен с этим. Если добавление отсутствующих функций в полную структуру слишком сложно, не делайте этого. То, что ASP.NET Core 2 работает только на .NET Core 2, на самом деле имеет смысл, хотя упоминание их как одного продукта, вероятно, было не лучшим способом описать их связь.

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

@davidfowl Думаю, дело не только в HTTP 2.0; если речь действительно идет о HTTP 2.0, не могли бы вы использовать ASP.NET Core 2.0 для NetFX, за исключением поддержки HTTP 2.0? Возможно, даже подключаемая модель, чтобы сообщество могло использовать HTTP 2.0 на NetFX, если бы оно действительно захотело?

@cokkiy @popcatalin81 @xprzemekw Если вам нечего сказать конструктивного, пожалуйста, воздержитесь от комментариев, такие комментарии никому не помогут.

Есть законные причины, по которым нужно сделать шаг, описанный @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134.

Причины, по которым его откладывают, включают (скажем, asp.net core 3.0):

• EF Core еще не готов заменить EF 6.0 из-за отсутствия многих функций.
• производство не готово System.Drawing замена
• нет System.DirectoryServices
• было упоминание о office xml sdk , но, похоже, оно уже доступно в netstandard по состоянию на 01 мая 2017 г. https://www.nuget.org/packages/DocumentFormat.OpenXml/
• другие пакеты, не входящие в сферу MS, недоступны в ядре .net (nhibernate, различные поставщики баз данных, ikvm)

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

• Люди переносили приложения на ядро ​​asp.net с устаревшими зависимостями, не собираясь переходить на ядро ​​.net.
• Не беспокойтесь о том, чтобы оставить netstandard позади и не слишком заботиться об этом.
• Некоторые сторонние пакеты вряд ли когда-либо будут перенесены на ядро ​​​​.net (что, возможно, делает их устаревшими, но это может быть только мое мнение).

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

@Куккимонсута

Люди переносили приложения на ядро ​​asp.net с устаревшими зависимостями, не собираясь переходить на ядро ​​.net.

Полностью согласен. Потому что Microsoft объявила, что ASP.NET Core будет работать как на .net core, так и на .net framework. И теперь оставлять их в AspNet Core 1.x нечестно.

Последнее резюме очень хорошее. Я просто хотел бы добавить пару вещей:

1.) Должна быть возможность писать службы Windows с .NET Core (я знаю, что демоны на платформах *NIX работают по-другому). Так что ServiceBase все равно понадобится, а это высокий приоритет вместе с EF.

2.) Кроме того, должна быть возможность писать автономные сервисы с .NET Core и дополнительно размещать их в вашем существующем полнофункциональном приложении .NET (т. е. бесплатный сервис из вашего приложения Windows Forms/WPF) для их расширения.

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

Полностью согласен. Потому что Microsoft объявила, что ASP.NET Core будет работать как на .net core, так и на .net framework. И теперь оставлять их в AspNet Core 1.x нечестно.

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

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

извините, мне тоже приходится напрягаться. Но почти 500 комментариев, я полагаю, что если я буду участвовать в этой проблеме как парень из Microsoft, у меня будет два варианта:
1: отключить звук
2: переосмыслить свое решение

@gingters Изменение csproj было в первую очередь связано с ядром _.net_, чтобы xamarin, asp.net, uwp и все остальные могли совместно использовать код, а также ссылаться на другие типы проектов, такие как собственный код.

Кроме того, он позволяет проектам asp.net core 2 ссылаться на полноценные фреймворковые проекты, опять же, через оболочку совместимости.

@qmfrederik

Возможно, даже подключаемая модель, чтобы сообщество могло использовать HTTP 2.0 на NetFX, если бы оно действительно захотело?

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

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

@aL3891

для того, чтобы xamarin, asp.net, uwp и все остальные могли обмениваться кодом

да. Точно. И это также включает приложение WPF/Windows Forms для использования библиотек .NET Core, что теперь невозможно, если вы хотите перейти на .NET Core 2.

Может ли кто-нибудь точно объяснить, почему, черт возьми, эти библиотеки не могут ориентироваться netstandard2.0 ?

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