Posted on 5. April 2021

GC Perf Infrastructure - Часть 1

Microsoft открывает новый проект GC Perf! Теперь это часть репозитория производительность .Net.

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

Во-вторых, в инфраструктуре много движущихся частей, и, поскольку она все еще находится в стадии разработки, я не удивлюсь, если вы столкнетесь с проблемами при ее использовании. Пожалуйста, будьте терпеливы, когда мы решаем проблемы! У нас нет много ресурсов, поэтому мы не сможем получить к ним доступ сразу. И, конечно, если вы хотите внести свой вклад, для нас это будет очень ценно. Я знаю многих людей, которые читают это, увлечены анализом производительности и проделали огромную работу по созданию / улучшению ее для .NET. А внесение вклада в анализ производительности – это фантастический способ узнать о настройке GC, если вы хотите начать с чего-то. Поэтому я настоятельно рекомендую вам внести свой вклад!

 

Топология

Мы обсудили, хотим ли мы открыть исходный код для этого в своем собственном репо, и пришли к выводу, что мы не будем делать это в основном из-за логистических соображений, поэтому это стало частью репозитория perf в каталоге src/benchmarks/gc (к которому я буду обращаться в качестве корневого каталога). Это не зависит от чего-либо это означает, что вам не нужно ничего создавать вне этого каталога, если вы просто хотите использовать инфракрасную часть GC perf.

Файл readme.md в корневом каталоге описывает общий рабочий процесс и основное использование. Дополнительную документацию можно найти в каталоге документов.

Есть 2 основных компонента инфраструктуры:

Запуск тестов производительности

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

Задание различных аргументов командной строки для генерации разных характеристик perf в тестах, например, разных коэффициентов построения для SOH / LOH и разных коэффициентов пиннинга;

Определение сборок для сравнения;

Задание различных сред, например, различных переменных env для указания конфигураций GC, работы в контейнерах или ситуаций с высокой загрузкой памяти;

Задание различных параметров для сбора трасс с помощью, GCCollectOnly или ThreadTime.

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

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

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

Источник для этого находится в exec dir.

Анализ производительности

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

Источник находится в  analysis.

Настройка анализа

После копирования репозитория с производительностью dotnet вы увидите файл readme в директории gc infra root. Настройка подробно описана в этом документе. Если вам просто нужен анализ, вам не нужно выполнять все шаги по настройке. Единственные шаги, которые вам нужны –

Установите Python. 3.7 является минимально необходимой версией и рекомендуемой версией. 3.8 есть проблемы с Jupyter Notebook. Я хотел указать на это, потому что 3.8 – последняя версия релиза на странице python.

Установите необходимые библиотеки python – вы можете сделать это через «py -m pip install -r src / needs.txt», как сказано в readme, и если ошибок не возникает, отлично; но вы можете получить ошибки с pythonnet, который является обязательным для анализа. На самом деле установка pythonnet может быть настолько хлопотной, что мы посвятили ей целый документ. Я надеюсь, что однажды в VSCode будет достаточно хороших библиотек для построения диаграмм на С#, и С# в Jupyter Notebook, будут работать,  поэтому нам больше не понадобится pythonnet.

Создайте библиотеку анализа С#, запустив «dotnet publish» в каталоге src\analysis\managed-lib dir.

Укажите, что анализировать

Допустим, вы собрали трассировку ETW (это может быть из .NET или .NET Core) вам нужно его проанализировать, какой процесс будет для вас интересен (в Linux вы собираете события для интересующего процесса с помощью dotnet-trace, но поскольку инфраструктура работает как в Windows, так и в Linux, это те же шаги). Определение процесса для анализа означает простую запись файла .yaml, который мы называем «файлом статуса теста». Из файла readme для файла состояния теста, который вы пишете только для анализа, нужны только эти 3 строки:

success: true

trace_file_name: x.etl # A relative path. Should generally match the name of this file.

process_id: 1234 # If you don’t know this, use the print-processes command for a list

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

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

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

C:\perf\src\benchmarks\gc>py . help

Сначала прочтите README.md. Для помощи с отдельной командой используйте py . command-name –help. (Вы можете пропустить —help –hidden чтобы увидеть скрытые аргументы.)

Запустите команду

[пропустить]

команды анализа

Команды для анализа результатов теста (файлы трассировки). Чтобы сравнить небольшое количество конфигурации, используйте diff. Для сравнения используйте chart-configs. Для подробного анализа одной трассы используйте analyze-single или chart-individual-gcs.

analysis-single: с учетом одной трассы, показателей печати и, при необходимости, показателей для отдельных GC.

analyse-single-gc: выводит подробную информацию об одном GC в пределах одной трассы.

[больше вывода опущено и выполнено некоторое форматирование вывода]

 

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

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

C: \ perf \ src \ benchmarks \ gc> py. помочь печатным процессам

 

Напечатайте все PID процесса и имена из файла трассировки.

[больше выходных данных пропущено; Я также сделал некоторое форматирование, чтобы избавиться от некоторых столбцов, чтобы строки не были слишком длинными]

 

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

C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderMSec

Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.

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

C:\perf\src\benchmarks\gc>py . chart-individual-gcs C:\traces\fragment\fragment.yaml –x-single-gc-metric Index –y-single-heap-metrics MarkOlderPromotedMB

Это покажет 8 куч. Подумайте о прохождении —show-n-heaps.

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

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

Вот пример .md, который показывает примеры использования некоторых команд. Обратите внимание, что анализ объединения еще не проверен – пиар вышел, и я хотел потратить больше времени на CR, прежде чем объединять его.

Источник



Posted on 25. June 2019

Выпуск .NET Core 3.0 Preview 5

Совсем недавно вышел .NET Core 3.0 Preview 5. Он содержит новый Json сериализатор, поддержку публикации исполняемых файлов из одного файла, обновление для отката времени выполнения и изменения в BCL. Не забудьте ознакомиться с улучшениями в .NET Core 3.0 Preview 4.

Загрузите .NET Core 3.0 Preview 5 на Ваш Windows, macOS и Linux уже сейчас.

Также были обновлены ASP.NET Core и EF Core.

WPF и Windows Forms Обновления

Вы должны увидеть улучшение производительности при запуске  WPF и Windows Forms. Сборки WPF и Windows Forms теперь скомпилированы заранее, с использованием crossgen. Многие пользователи уже заметили улучшения при запуске между Preview 4 и Preview 5.

Было опубликовано больше WPF кода как часть .NET Core 3.0 Preview 4. Уже в Preview 7 будет окончательная WPF публикация.

Новый SqlClient

SqlClient – это поставщик данных, который Вы используете для доступа к SQL Server и базе данных SQL Azure либо через один из популярных .NET O/RM, например EF Core или Dapper, либо напрямую через API-интерфейсы ADO.NET.

В течение многих лет SqlClient поставлялся как часть сборки System.Data.dll в .NET Framework. Каждый раз, когда для использования новых функций SQL Server требовались изменения в SqlClient, приходилось ждать возможности, чтобы обновить .NET Framework на Windows. Раньше это работало нормально, поскольку новые функции SQL Server по-прежнему регулярно выпускались, разработка новых функций переходила на .NET Core и все вело к улучшению стабильности .NET Framework, и было больше смысла выводить разработку SqlClient из-под диапазона.

Введите Microsoft.Data.SqlClient, новую версию SqlClient, которую Вы можете добавить как NuGet пакет в .NET Framework и .NET Core (включая .NET Core 3.0) приложениях, которые сегодня запускаются в режиме предварительного просмотра.

Что нового в Microsoft.Data.SqlClient?

Отсутствие поддержки Always Encrypted в .NET Core было основной проблемой, которая была решена в этом предварительном просмотре.

Также ведется работа над двумя новыми функциями, доступными как для .NET Framework, так и для .NET Core:

  • Классификация данных
  • Поддержка UTF-8

В настоящее время планируется выпустить эти и другие улучшения в Microsoft.Data.SqlClient в те же сроки, что и в .NET Core 3.0.

Что значит для System.Data.SqlClient?

System.Data.SqlClient по-прежнему будет поддерживаться и получать важные обновления безопасности, поэтому нет необходимости перемещения, если Ваше приложение взаимодействует с ним. Но если Вы хотите воспользоваться новыми функциями, Вам следует рассмотреть обновление к Microsoft.Data.SqlClient. Процесс должен быть простым для многих приложений: просто установите пакет и обновите пространство SqlClient имен в Вашем коде. В некоторых других случаях потребуются изменения в конфигурации или обновленных O/RM версиях, которые зависят от нового SqlClient.

Следите за этим блог постом, чтобы узнать больше информации о новом SqlClient.

Публикация отдельных EXE-файлов

Теперь Вы можете публиковать однофайловый исполняемый файл с помощью dotnet publish. Эта форма одиночного EXE-файла – фактически самораспаковывающийся исполняемый файл. Он содержит все зависимости, включая нативные зависимости, в качестве ресурсов. При запуске он копирует все зависимости во временный каталог и загружает их туда. Распаковать зависимости нужно всего один раз. После этого запуск происходит быстро и просто.

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

К примеру, чтобы создать отдельное EXE-приложение для 64-разрядной Windows версии:

dotnet publish -r win10-x64 /p:PublishSingleFile=true

Отдельные EXE-приложения должны соответствовать архитектуре. В результате необходимо указать идентификатор времени выполнения.

Смотрите Single file bundler для получения дополнительной информации.

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

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

JSON Сериализатор

Новый JSON сериализатор расположен поверх высокопроизводительных Utf8JsonReader и Utf8JsonWriter. Он десериализует объекты из JSON и сериализует объекты в JSON. Выделение памяти минимально и включает в себя поддержку чтения и записи JSON с Stream в асинхронном режиме.

Для начала используйте JsonSerializer класс в пространстве System.Text.Json.Serialization имен. Смотрите документацию с дополнительной информацией и примерами. Набор функций продолжает расширяться для будущих preview-версий.

Изменение дизайна Utf8JsonWriter

Основываясь на отзывах об удобстве использования и надежности, был внесен ряд изменений в Utf8JsonWriter дизайн, который был добавлен во второй preview-версии. Writer теперь является обычным классом, а не ref структурой, и реализует IDisposable. Это позволяет добавлять поддержку записи в потоки напрямую. Кроме того, был удален JsonWriterState, и теперь JsonWriterOptions необходимо передавать непосредственно в Utf8JsonWriter, который поддерживает свое собственное состояние. Чтобы помочь компенсировать распределение, Utf8JsonWriter имеет новый API сброса, который позволяет Вам сбросить его состояние и повторно использовать модуль записи. Также была добавлена встроенная реализация IBufferWriter с именем ArrayBufferWriter, которую можно использовать с Utf8JsonWriter. Вот фрагмент кода, который показывает изменения:

// New, built-in IBufferWriter that's backed by a grow-able array
var arrayBufferWriter = new ArrayBufferWriter();
 
// Utf8JsonWriter is now IDisposable
using (var writer = new Utf8JsonWriter(arrayBufferWriter, new JsonWriterOptions { Indented = true }))
{
 
   // Write some JSON using existing WriteX() APIs.
 
   writer.Flush(); // There is no isFinalBlock bool parameter anymore
}

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

Index и Range

В предыдущем предварительном просмотре платформа поддерживала Index и Range, предоставляя перегрузки общих операций, таких как индексаторы и методы, такие как Substring, которые принимали значения Index и Range. Основываясь на отзывах пользователей, все было упрощено и позволило компилятору вызывать существующие индексаторы. В документе «Index и Range изменения» содержится более подробная информация о том, как это работает, но основная идея заключается в том, что компилятор может вызывать индексатор на int основе, извлекая смещение из заданного значения Index. Это означает, что индексирование с использованием Index теперь будет работать для всех типов, которые предоставляют индексатор и имеют Count или Length свойство. Компилятор обычно не может использовать существующий индексатор для Range, потому что он возвращает только единичные значения. Однако теперь компилятор разрешает индексирование с использованием Range, когда тип предоставляет индексатор, который принимает Range, или Slice метод. Это позволяет Вам выполнять индексацию с использованием Range, а также работать с интерфейсами и типами, которые Вы не контролируете, предоставляя метод расширения.

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

string s = "0123456789";
char lastChar = s[^1]; // lastChar = '9'
string startFromIndex2 = s[2..]; // startFromIndex2 = "23456789"

Следующие String методы были удалены:

public String Substring(Index startIndex);
public String Substring(Range range);

Любой код, использующий эти String методы, должен быть обновлен для использования индексаторов

string substring = s[^10..]; // Replaces s.Substring(^10);
string substring = s[2..8];   // Replaces s.Substring(2..8);

Следующий Range метод ранее возвращал OffsetAndLength:

public Range.OffsetAndLength GetOffsetAndLength(int length);

Теперь он просто вернет строку:

public ValueTuple GetOffsetAndLength(int length);

Здесь продолжается компиляция и запуск, как и раньше:

(int offset, int length) = range.GetOffsetAndLength(20);

Новая японская эра (Reiwa)

1 мая 2019 года в Японии началась новая эра - так называемая Reiwa. Программное обеспечение, поддерживающее японские календари, например .NET Core, должно быть обновлено в соответствии с требованиями Reiwa. .NET Core и .NET Framework были обновлены и корректно обрабатывают японское форматирование и парсинг даных.

.NET полагается на операционную систему или другие обновления для правильной обработки Reiwa данных. Если Вы или Ваши клиенты используете Windows, загрузите последние Windows обновления. Если Вы используете macOS или Linux, загрузите и установите ICU 64.2 версию, которая поддерживает новую японскую эру.

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

Внутренние аппаратные API изменения

Avx2.ConvertToVector256* методы были изменены, чтобы возвращать подписанный тип, а не неподписанный. Это помещает их в строку с Sse41.ConvertToVector128* методами и соответствующими встроенными функциями. Например, Vector256 ConvertToVector256UInt16(Vector128) теперь является Vector256 ConvertToVector256Int16(Vector128).

Sse41/Avx.ConvertToVector128/256* методы были разделены на методы, которые принимают Vector128/256, и методы, которые принимают T*. Например, ConvertToVector256Int16(Vector128) теперь поддерживает перегрузку ConvertToVector256Int16 (byte*). Это было сделано потому, что основная инструкция, которая принимает адрес, выполняет частичное векторное чтение (а не полное векторное или скалярное чтение). Это означало, что генерирация оптимального кодирования команд не всегда была возможной и пользователю приходилось выполнять чтение из памяти. Это разделение позволяет пользователю явно выбирать форму адресации инструкции при необходимости (например, когда у Вас еще нет Vector128).

Записи перечисления FloatComparisonMode и Sse/Sse2.Compare методы были переименованы, чтобы уточнить, что операция упорядочена / неупорядочена. Они также были переупорядочены для обеспечения большего взаимодействия между SSE и AVX реализациями. Например, Sse.CompareEqualOrderedScalar теперь является Sse.CompareScalarOrderedEqual. Аналогично, для AVX версий Avx.CompareScalar (left, right, FloatComparisonMode.OrderedEqualNonSignalling) теперь Avx.CompareScalar(left, right, FloatComparisonMode.EqualOrderedNonSignalling).

Обновление политики среды выполнения .NET Core

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

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

Существует новый RollForward, который принимает следующие значения:

  • LatestPatch — Переход к самой высокой версии. Это отключит второстепенный откат версии.
  • Minor — Переход к самой меньшей минорной версии, если запрашиваемая минорная версия отсутствует. Если запрашиваемая дополнительная версия присутствует, используется LatestPatch политика. Это политика по умолчанию.
  • Major — Переход к самой меньшей высокой версии и меньшей минорной версии, если запрашиваемая основная версия отсутствует. Если запрашиваемая основная версия присутствует, то используется дополнительная Minor политика.
  • LatestMinor — Переход к большей минорной версии, даже если запрошенная минорная версия присутствует.
  • LatestMajor — Переход к большей и большей минорной версии, даже если присутствует запрашиваемая главная версия.
  • Disable — Не откатывайтесь заранее. Привязывайтесь только к указанной версии. Эта политика не рекомендована для общего использования, так как она отключает возможность перехода к последним исправлениям. Рекомендуется только для тестирования.
Для получения дополнительной информации изучите блог посты Runtime Binding Behavior и dotnet/core-setup #5691.

Уменьшение докерных изображений .NET Core для Linux

Размер среды выполнения был сокращен примерно на 10 МБ, с помощью функции «частичного кроссгена».

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

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

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

В будущих выпусках будет расширено использование частичного кроссгена.

Docker Обновления

Теперь поддерживаются Alpine ARM64 образы. Также Linux образ по умолчанию переключен на Debian 10 / Buster. Debian 10 еще не выпущен. Есть вероятность, что он будет выпущен до .NET Core 3.0.

Добавилась поддержка Ubuntu 19.04 / Disco. Обычно не добавляется поддержка выпусков Ubuntu, не относящихся к LTS, но поддержка 19.04 была добавлена как часть процесса готовности к Ubuntu 20.04, следующей версии LTS. Поддержка для 19.10 будет добавлена при его выпуске.

О том, как использовать .NET Core и Docker вместе, Вы можете ознакомиться подробно здесь.

Обновления AssemblyLoadContext

AssemblyLoadContext продолжает улучшаться, чтобы в будущем простые модели плагинов работали без особых усилий (или кода) с Вашей стороны, и чтобы были возможны сложные модели плагинов. В Preview 5 была добавлена неявная загрузка типов и сборок через Type.GetType, когда вызывающая сторона не является приложением, например, сериализатором.

См. документ AssemblyLoadContext.CurrentContextualReflectionContext для получения дополнительной информации.

COM-вызываемые управляемые компоненты

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

В .NET Framework использовался mscoree.dll в качестве COM-сервера. Вместе с .NET Core мы предоставляем встроенную библиотеку DLL запуска, которая добавляется в каталог bin компонента при сборке COM-компонента.

Изучите COM Server Demo, чтобы опробовать эту новую возможность.

Поддержка больших GC страниц

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

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

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

В заключении

Обязательно попробуйте новый выпуск .NET Core 3.0. Пожалуйста, делитесь Вашими отзывами или комментариями на GitHub. Ваш вклад важен для будущего развития!

Взгляните на .NET Core 3.0 Preview 1, Preview 2, Preview 3 и Preview 4, если Вы пропустили эти выпуски. В этом посте Вы можете узучить полный набор новых возможностей, которые были добавлены к выпуску .NET Core 3.0.



Posted on 11. June 2019

Перемещение образца WPF приложения на .NET Core 3 (Часть 1)

Ольга Гавриш недавно написала пост о том, как перенести WinForms приложение с .NET Framework на .NET Core. В этом блог посте будут выполняться шаги по переносу WPF-приложения на .NET Core 3. Многие из этих шагов будут знакомы Вам из поста Ольги, но здесь добавлены некоторые дополнительные общие зависимости, с которыми пользователи могут столкнуться, например, использование WCF  клиента или сторонних пакетов пользовательского интерфейса.

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

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

Видео инструкции

Если предпочитаете видео инструкции по перемещению приложения, Вы можете просмотреть ролики на YouTube, посвященный переносу приложения.

О примере

Для этого примера было написано простое приложение для торговли товарами под названием «Bean Trader». У пользователей приложения есть учетные записи с разным количеством бобов (которые бывают четырех разных цветов). С этим приложением, пользователи могут предлагать и принимать сделки с другими пользователями. Приложение не очень большое (около 2000 строк кода), но, с точки зрения сложности, на шаг впереди «Hello World». Оно создано для того, чтобы Вы могли видеть некоторые проблемы, с которыми пользователи могут столкнуться при переносе реальных приложений.

Интересные зависимости в приложении:

  • Соединение WCF с бэкенд-трейдингом через двойной NetTcp канал
  • Моделирование пользовательского интерфейса и MahApps.Metro диалогов
  • Внедрение зависимостей с помощью Castle.Windsor (хотя, многие DI-решения, включая Microsoft.Extensions.DependencyInjection, могут использоваться в этом сценарии)
  • Настройки приложения в app.config и реестре
  • Различные ресурсы и resx файлы

Исходный код этого приложения доступен на GitHub. Исходный источник (до переноса) доступен в NetFx\BeanTraderClient каталоге. Последнее перемещенное приложение находится в NetCore\BeanTraderClient директории. Бэкэнд-сервис, с которым должно соединяться приложение, доступен в BeanTraderServer папке.

Отказ

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

Обзор процесса перемещения

Процесс перехода с .NET Framework на .NET Core состоит из четырех основных этапов.

1. Во-первых, полезно подготовиться к перемещению, разобраться в зависимостях проекта и перемещать проект в легко переносимом состоянии.

  1. Используйте такие инструменты, как .NET Portability Analyzer, для изучения .NET Framework зависимостей.
  2. Также стоит обновить NuGet ссылки для использования формата и, возможно, придется обновить версии NuGet пакетов.

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

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

4. В-четвертых, не забудьте протестировать перенесенное приложение! Некоторые .NET Core/.NET Framework различия не проявляются до времени выполнения (хотя существуют Roslyn анализаторы кода, помогающие идентифицировать эти случаи).

Шаг 1: Подготовка

Образец клонирован и готов к работе? Супер, теперь можно начать!

Основная проблема при перемещение .NET Framework приложения на .NET Core заключается в том, что его зависимости в .NET Core могут работать по-разному (или вообще не работать!). Сейчас перемещение стало намного проще, чем раньше – многие NuGet пакеты теперь нацелены на .NET Standard, и, начиная с .NET Core 2.0, .NET Framework и .NET Core стали довольно похожими. Тем не менее, некоторые различия остаются (как в поддержке NuGet пакетов, так и в доступных .NET API).

Обновление NuGet ссылок к

Старые .NET Framework проекты обычно перечисляют свои NuGet зависимости в packages.config файле. Однако новый формат файла проекта в SDK стиле по-разному ссылается на NuGet пакеты. Для ссылки на NuGet зависимости он использует элементы в самом csproj файле (а не в отдельном файле конфигурации). К счастью, csproj файлы старого стиля также могут использовать современный синтаксис.

При перемещении есть два преимущества использования ссылок в стиле:

  1. Это стиль NuGet ссылки, который потребуется для нового файла .NET Core проекта. Если Вы уже используете , эти элементы файла проекта можно скопировать и вставить непосредственно в новый проект.
  2. В отличие от packages.config файла, элементы ссылаются только на самые важные зависимости, от которых напрямую зависит Ваш проект. Все остальные переходные NuGet пакеты будут определены во время восстановления и записаны в автоматически сгенерированный obj\project.assets.json файл. Это значительно упрощает рассуждение о том, какие зависимости есть у Вашего проекта, что полезно при определении того, будут ли необходимые зависимости работать на .NET Core или нет.

Итак, первый шаг к перемещению Bean Trader образца – это подготовить его к использованию NuGet ссылок. С Visual Studio это очень легко. Просто щелкните правой кнопкой мыши по packages.config файлу проекта в Visual Studio Solution Explorer и выберите «Перенести packages.config в PackageReference».

Появится диалоговое окно, показывающее вычисленные самые важные NuGet зависимости и спрашивающее, какие другие NuGet  пакеты должны быть перемещены к этому уровню. Ни один из этих других пакетов не должен быть высокого уровня для Bean Trader образца, поэтому Вы можете снять все эти флажки. Затем нажмите «ОК», и packages.config файл будет удален, а элементы будут добавлены в файл проекта.

Ссылки в стиле не хранят NuGet пакеты локально в папке «пакетов» (вместо этого они хранятся глобально, в качестве оптимизации), поэтому после перемещения Вам нужно будет отредактировать csproj файл и удалить элементы, относящиеся к FxCop анализаторам, которые ранее были из .. \packages директории.

Просмотрите NuGet пакеты

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

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

При нацеливании на .NET Core 3 должны работать любые пакеты, нацеленные на .NET Core или .NET Standard (поскольку .NET Core реализует .NET Standard). Вы также можете использовать пакеты, нацеленные на .NET Framework, но это представляет некоторый риск. Разрешены зависимости от .NET Core к .NET Framework, поскольку .NET Core и .NET Framework достаточно похожи, поэтому такие зависимости часто работают без проблем. Однако, если пакет пытается использовать .NET API, которого нет в .NET Core, Вы столкнетесь с трудностями во время работы. По этой причине Вы должны ссылаться на .NET Framework пакеты только тогда, когда другие опции недоступны, и помнить, что это создаст нагрузку на тестирование.

В случае примера Bean Trader есть следующие NuGet  зависимости:

  • Castle.Windsor, версия 4.1.1. Этот пакет предназначен для .NET Standard 1.6, поэтому он будет работать на .NET Core.
  • Microsoft.CodeAnalysis.FxCopAnalyzers, версия 2.6.3. Это метапакет, поэтому неясно, какие платформы он поддерживает, но в документации указано, что его новейшая версия (2.9.2) будет работать как для .NET Framework, так и для .NET Core.
  • Nito.AsyncEx, версия 4.0.1. Этот пакет не предназначен для .NET Core, но более новая версия 5.0 сможет это сделать. Это часто происходит при миграции, потому что многие NuGet пакеты за последний год добавили поддержку .NET Standard, но более старые проекты будут использовать более старые версии этих пакетов. Если разница версий незначительна, ее можно легко обновить до более новой версии. Поскольку это серьезное изменение версии, Вы должны быть осторожны при обновлении, поскольку в пакете могут произойти критические изменения.
  • MahApps.Metro, версия 1.6.5. Этот пакет также не предназначен для .NET Core, но имеет более новую preview-версию (2.0-alpha).

Все NuGet зависимости из примера Bean Trader предназначены либо для .NET Standard/.NET Core, либо для их более новых версий, поэтому у Вас вряд ли возникнут какие-либо проблемы с блокировкой.

Если бы существовали пакеты, не предназначенные для .NET Core или .NET Standard, пришлось бы подумать о других альтернативах:

  • Есть ли другие похожие пакеты, которые можно использовать вместо этих? Иногда NuGet авторы публикуют отдельные .Core версии библиотек, специально предназначенные для .NET Core. Пакеты Enterprise Library – пример того, как сообщество публикует альтернативы с .NetCore расширением.
  • Если альтернатив нет, Вы можете продолжить использование пакетов, нацеленных на .NET Framework, имея в виду, что Вам потребуется тщательно их протестировать после запуска на .NET Core.

Обновите NuGet пакеты

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

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

В случае примера Bean Trader все необходимые обновления могут быть легко выполнены (с помощью диспетчера NuGet пакетов в Visual Studio) с одним исключением: обновление с MahApps.Metro 1.6.5 до 2.0 выявляет серьезные изменения, связанные с API-интерфейсами для управления темами и акцентами.

В идеале приложение должно быть обновлено, чтобы использовать более новую версию пакета (так как оно, скорее всего, будет работать на .NET Core). Однако в некоторых случаях это может быть неосуществимо. В этом случае MahApps.Metro не будет обновляться, потому что этот туториал сосредоточен на переходе на .NET Core 3, а не на MahApps.Metro 2. Кроме того, это .NET Framework зависимость с низким уровнем риска, поскольку приложение Bean Trader выполняет только небольшую часть MahApps.Metro. Конечно, после завершения миграции потребуется тестирование, чтобы убедиться, что все работает.

После обновления NuGet пакетов до последних версий группа элементов в файле проекта Bean Trader должна выглядеть следующим образом:

Анализ переносимости .NET Framework

Теперь рассмотрим зависимости .NET Framework API. Инструмент .NET Portability Analyzer полезен для понимания того, какие из .NET API, которые использует Ваш проект, доступны на других .NET платформах.

Этот инструмент поставляется в виде Visual Studio плагина, инструмента командной строки или в виде простого графического интерфейса пользователя, который упрощает его параметры и всегда сообщает о совместимости с .NET Core 3.

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

1. Загрузите API Portability Analyzer.

2. Убедитесь, что приложение .NET Framework для переноса собралось успешно.

3. Запустите API-порт с помощью командной строки, например:

  1. ApiPort.exe analyze -f -r html -r excel -t “.NET Core”
  2. Аргумент -f указывает путь, содержащий двоичные файлы для анализа. Аргумент -r указывает, какой формат выходного файла Вам нужен. Будут полезны как HTML, так и Excel форматы. Аргумент -t указывает, с какой .NET платформой будет анализироваться использование API. В данном случае нужен .NET Core, поскольку именно эта платформа является целевой.  Так как версия не указана, по умолчанию для API Port используется последняя версия платформы (в данном случае – .NET Core 3.0).

Когда Вы откроете HTML-отчет, в первом разделе будут перечислены все проанализированные двоичные файлы и какой процент используемых им .NET API доступен на целевой платформе. Сам по себе этот процент не очень значимый. Что более полезно, так это увидеть конкретные API, которые отсутствуют. Для этого щелкните имя сборки или прокрутите вниз до отчетов по отдельным сборкам.

Вам нужно беспокоиться только о тех сборках, для которых у Вас есть исходный код. В отчете Bean Trader ApiPort перечислено много двоичных файлов, но большинство из них относится к NuGet пакетам. Например, Castle.Windsor показывает, что он зависит от некоторых System.Web API интерфейсов, отсутствующих в .NET Core. Это не проблема, потому что Castle.Windsor поддерживает .NET Core. Обычно NuGet пакеты имеют разные двоичные файлы для использования на разных  .NET платформах, поэтому независимо от того, использует ли .NET Framework версия Castle.Windsor System.Web API-интерфейсы или нет, это не имеет значения, если пакет также предназначен для .NET Standard или. NET Core.

В случае примера Bean Trader единственный двоичный файл, который нужно изучить – BeanTraderClient, и в отчете показано, что отсутствуют только два .NET API – System.ServiceModel.ClientBase.Close и System.ServiceModel.ClientBase.Open

Это вряд ли избавит от проблем, потому что WCF Client API (в основном) поддерживаются в .NET Core, поэтому для этих центральных API должны быть альтернативы. Фактически, глядя на System.ServiceModel .NET Core (используя https://apisof.net), можно увидеть, что в .NET Core есть асинхронные альтернативы.

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

Шаг 2: Перемещение файла проекта

Поскольку .NET Core использует новый формат файла проекта в SDK стиле, существующий csproj файл не будет работать. Нам понадобится новый файл проекта для .NET Core версии приложения Bean Trader. Если Вам не нужно было собирать .NET Framework версию приложения в будущем, Вы могли бы просто заменить существующий csproj файл. Но часто разработчики хотят создавать обе версии – особенно тогда, когда .NET Core 3 все еще находится в режиме предварительного просмотра.

Есть три варианта, где должен размещаться новый csproj файл, каждый из которых имеет свои плюсы и минусы:

 

  1. Вы можете использовать многоцелевой таргетинг (указав несколько целей), чтобы получить один файл проекта, который создаст .NET Core и .NET Framework версии решения. В будущем это, вероятно, будет лучшим вариантом. Однако, на данный момент, некоторые функции плохо работают с многоцелевым таргетингом. Поэтому сейчас рекомендуется иметь отдельные файлы проекта для версий приложений, ориентированных на .NET Core и .NET Framework.
  2. Вы можете поместить новый файл проекта в другую директорию. Это облегчит разделение сборки, но означает, что Вы не сможете использовать преимущества новой системы проектов, позволяющей автоматически добавлять C# и XAML файлы. Также необходимо будет добавить элементы для XAML ресурсов, чтобы они были встроены с правильными путями.
  3. Вы можете поместить новый файл проекта в ту же директорию, что и текущий файл проекта. Это позволяет избежать проблем, связанных с предыдущим параметром, но приведет к конфликту obj и bin папок для двух проектов. Если Вы одновременно открываете только один из проектов, это не будет проблемой. Но если они оба будут открыты одновременно, Вам нужно будет обновить проекты, чтобы использовать разные пути вывода и промежуточные пути вывода.

 

Лучший вариант – пункт 3 (чтобы файлы проекта работали бок о бок), поэтому этот подход будет использоваться в качестве примера.

Для создания нового файла проекта, обычно используется команда dotnet new wpf во временном каталоге, чтобы сгенерировать файл проекта, а затем скопировать / переименовать его в нужное место. Существует также созданный сообществом инструмент CsprojToVs2017, который может автоматизировать некоторые процессы миграции. Этот инструмент полезен, но все еще нуждается в улучшении, чтобы  все детали миграции были верны. Одна конкретная область, которую инструмент не обрабатывает до конца, – это миграция NuGet пакетов из packages.config файлов. Если инструмент запускается в файле проекта, который все еще использует файл packages.config для ссылки на NuGet пакеты, он автоматически мигрирует в элементы, но добавит элементы для всех пакетов, а не только для верхнего уровня. Однако если Вы уже перешли на элементы с помощью Visual Studio, то этот инструмент может помочь с остальной частью конвертирования. Перенос вручную даст лучшие результаты, если у Вас только несколько проектов. Но если Вы портируете десятки или сотни файлов проекта, то такой инструмент, как CsprojToVs2017, может Вам помочь.

Так что, запустите dotnet new wpf во временном каталоге и переместите созданный csproj файл в BeanTraderClient папку и переименуйте его в BeanTraderClient.Core.csproj.

Поскольку новый формат файла проекта автоматически включает C#, resx и XAML файлы, которые он находит в своей директории, файл проекта уже почти готов! Чтобы завершить миграцию, одновременно откройте старые и новые файлы проекта и просмотрите старый, чтобы увидеть, нужно ли переносить какую-либо информацию, содержащуюся в нем. В этом случае следующие элементы должны быть скопированы в новый проект:

 

  • , и свойства должны быть скопированы.
  • Также нужно добавить false свойство в новый файл проекта, поскольку образец Bean Trader включает атрибуты уровня сборки в файле AssemblyInfo.cs (например, [AssemblyTitle]). По умолчанию новые проекты в SDK стиле автоматически генерируют эти атрибуты на основе свойств в csproj файле. Поскольку в этом случае это не нужно (автоматически сгенерированные атрибуты будут конфликтовать с теми что из AssemblyInfo.cs), Вам нужно отключить автоматически сгенерированные атрибуты с помощью .
  • Хотя resx файлы автоматически добавляются в качестве встроенных ресурсов, другие элементы, например изображения, не добавляются. Итак, скопируйте элементы для того, чтобы вставить изображения и значки файлов. Вы можете упростить png ссылки на одну строку, используя поддержку нового формата файла проекта для сокращения шаблонов: .
  • Аналогично, элементы будут включены автоматически, но по умолчанию они не будут скопированы в директорию выхода. Поскольку проект Bean Trader включает в себя элемент, который копируется в директорию выхода (с использованием PreserveNewest), необходимо обновить автоматически заполненный элемент для этого файла, например:
  • Образец Bean Trader содержит XAML файл (Default.Accent.xaml) в качестве Содержимого (а не Страницы), поскольку темы и акценты, определенные в этом файле, загружаются из XAML файла во время выполнения, а не встраиваются в само приложение. Новая система проекта автоматически содержит этот файл в виде <Страницы>, разумеется, поскольку это XAML файл. Итак, нужно удалить как XAML файл, так и страницу () и добавить его в качестве содержимого:
  • Наконец, добавьте NuGet ссылки, скопировав со всеми элементами. Если бы ранее NuGet пакеты не обновлялись до версий, совместимых с .NET Core, Вы могли бы сделать это сейчас, когда ссылки на пакеты находятся в специфичном для .NET Core проекте.

 

На этом этапе должна появиться возможность добавить новый проект в решение BeanTrader и открыть его в Visual Studio. Проект должен выглядеть правильно в Solution Explorer и dotnet restore BeanTraderClient.Core.csproj должен успешно восстановить пакеты (с двумя ожидаемыми предупреждениями, связанными с MahApps.Metro версией, которая используется для нацеливания на .NET Framework).

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

Источник



Posted on 31. May 2019

.NET Framework 4.8 [Part 2]

WCF – ServiceHealthBehavior

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

ServiceHealthBehavior – это поведение WCF сервиса, которое расширяет IServiceBehavior. При добавлении в коллекцию ServiceDescription.Behaviors будет включено следующее:

  • Возвращение состояния работоспособности сервиса с помощью ответов HTTP кода. В строке запроса можно указать код HTTP состояния для выполнения запроса проверки HTTP / GET работоспособности.
  • Публикация работоспособности сервиса: специфичные для сервиса детали, включая состояние сервиса и количество дросселей, отображаются с помощью HTTP / GET-запроса, используя “?health” строку запроса. Легкий доступ к отображаемой информации важны при устранении проблем WCF сервиса.

Конфигурация ServiceHealthBehavior:

Существует два способа предоставления конечной точки работоспособности и публикации информации о работоспособности WCF сервиса: с помощью кода или с помощью файла конфигурации.

  1. Включите конечную точку работоспособности, используя код
  2. Включите конечную точку работоспособности, используя конфигурацию

Верните статус работоспособности сервиса с помощью HTTP ответов кода:

Состояние работоспособности может запрашиваться параметрами запроса (OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded). HTTP ответ кода (200 – 599) можно указать для каждого параметра запроса. Если HTTP ответ кода отсутствует для параметра запроса, по умолчанию используется 503 HTTP.

Параметры и примеры запросов:

1. OnServiceFailure: 

  • Пример: путем https://contoso:81/Service1?health&OnServiceFailure=450 запроса, код состояния HTTP-ответа 450 возвращается, когда ServiceHost.State больше, чем CommunicationState.Opened.

2. OnDispatcherFailure:

  • Пример: при запросе https://contoso:81/Service1?health&OnDispatcherFailure=455 код состояния HTTP 455 ответа возвращается, когда состояние любого из диспетчеров каналов больше, чем CommunicationState.Opened.

3. OnListenerFailure:

  • Пример: путем запроса https://contoso:81/Service1?health&OnListenerFailure=465 код состояния HTTP 465 ответа возвращается, когда состояние любого из прослушивателей канала больше, чем CommunicationState.Opened.

4. OnThrottlePercentExceeded: указывает процент {1 – 100}, который инициирует ответ, и его HTTP-код ответа {200 – 599}.

  • Пример: путем запроса https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500 когда процент газа равен или превышает 95%, HTTP ответ кода 500; когда процент равен или больше 70% и меньше 95%, возвращается 350; в противном случае 200 возвращается. 

Публикация сервиса здоровья:

После включения конечной точки работоспособности состояние работоспособности сервиса может отображаться либо в html формате (указав строку запроса: https://contoso:81/Service1?health&Xml), либо в xml формате (указав строку запроса: https://contoso:81/Service1?health&Xml). https://contoso:81/Service1?health&NoContent возвращает пустую HTML-страницу.

Примечание:

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

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

WPF – экранные рассказчики больше не объявляют элементы с видимостью «Свернутый» или «Скрытый»

Элементы со свернутой или скрытой видимостью больше не объявляются программами чтения с экрана. Пользовательские интерфейсы, содержащие элементы с видимостью Свернутый или Скрытый, могут быть искажены программами чтения с экрана, если такие элементы объявлены пользователю. В .NET Framework 4.8 WPF больше не включает в себя элементы «Свернутый» или «Скрытый» в Control View структуры UIAutomation, поэтому программы чтения с экрана больше не могут объявлять эти элементы.

WPF – Свойство SelectionTextBrush для использования с Non-Adorner текстовым выделением

В .NET Framework 4.7.2 версии, в WPF добавилась возможность выделения TextBox и PasswordBox текста без использования adorner (см. здесь). Цвет переднего плана выделенного текста в этом сценарии был определен с помощью SystemColors.HighlightTextBrush.

В .NET Framework 4.8 будет добавлено новое свойство – SelectionTextBrush, которое позволит разработчикам выбирать конкретную кисть для выбранного текста при использовании выделения текста, основанного на non-adorner выделении текста.

Это свойство работает только для производных элементов управления TextBoxBase и PasswordBox в WPF приложениях с включенным выделением текста, не основанным на графическом элементе. Оно не работает на RichTextBox. Если выбор текста, не основанного на объявлении, не включен, это свойство игнорируется.

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

В результате выбор текста будет выглядеть так:

Вы можете комбинировать использование SelectionBrush и SelectionTextBrush для создания любой подходящей цветовой комбинации фона и переднего плана.

WPF – Усовершенствования с высоким разрешением

В WPF добавлена поддержка Per-Monitor V2 DPI Awareness и смешанного DPI режима в .NET 4.8. Дополнительную информацию об этих Windows концепциях смотрите здесь.

В последнем руководстве разработчика по созданию WPF приложений говорится, что только приложения с чистым WPF кодом будут бесперебойно работать в WPF приложениях с высоким разрешением и что элементы управления Hosted HWND и Windows Forms будут поддерживаться не полностью.

В .NET 4.8 улучшена поддержка взаимодействия между HWND и Windows Forms в WPF приложениях с высоким разрешением на платформах, которые поддерживают Mixed-Mode DPI (Windows 10 версия 1803). Когда размещенные элементы управления HWND или Windows Forms создаются как масштабированные Mixed-Mode DPI окна (как описано в документации «Mixed-Mode DPI маштабирование и API-интерфейсы с DPI поддержкой» путем вызова SetThreadDpiHostingBehavior и SetThreadDpiAwarenessContext API), можно будет разместить такое содержимое в PerF Monitor V2 WPF приложении, и маштабировать их размер соответствующим образом.

Поддержка режима Per-Monitor V2 DPI осведомленности также позволяет размещать WPF элементы управления (т.е. помещать их в родительское окно) под нативным окном в приложении с высоким разрешением. Поддержка Per-Monitor V2 DPI Awareness будет доступна в Windows 10 версии 1607 (Anniversary Update). Windows добавляет поддержку дочерних HWND для получения уведомлений об изменении DPI, когда Per-Monitor V2 DPI Awareness режим включен через манифест приложения.

WPF использует эту поддержку, чтобы гарантировать, что элементы управления, размещенные в собственном окне, могут реагировать на DPI изменения и обновляться самостоятельно. Например, WPF элемент управления, размещенный в Windows Forms или Win32 приложении, которое отображается как Per Monitor V2, теперь сможет корректно реагировать на DPI изменения и сам обновляться.

Обратите внимание, что Windows поддерживает Mixed-Mode DPI масштабирование в Windows 10 версии 1803, тогда как Per-Monitor V2 поддерживается в версии 1607 и выше.

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

1. Включите Per-Monitor DPI в Вашем приложении

  • Включите Per-Monitor V2 в Вашем app.manifest

2. Включите поддержку высокого разрешения в WPF

  • Нацельте .NET Framework 4.6.2 и выше

а также

3. Установите AppContext переключатель в Вашем app.config

Или же

Установите AAppContextSwitch Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false в App.Config, чтобы включить поддержку Per-Monitor V2 и Mixed-Mode DPI, внедренную в .NET 4.8.

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

Переключатели AppContext также могут быть установлены в реестре. Вы можете обратиться к AppContext Классу для получения дополнительной документации.

WPF – Поддержка свойства UIAutomation ControllerFor

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

Новый виртуальный метод был добавлен в AutomationPeer:

Чтобы предоставить значение для свойства ControllerFor, просто переопределите этот метод и верните список AutomationPeers для элементов управления, которыми манипулирует этот AutomationPeer:

WPF – Подсказки по доступу с клавиатуры

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

Чтобы включить эту функцию, приложению необходимо настроить таргетинг на .NET Framework 4.8 или зарегистрироваться через AppContext переключатель «Switch.UseLegacyAccessibilityFeatures.3» и «Switch.UseLegacyToolTipDisplay».

Пример App.config файла:

 

 
 
      
         
     
   
     
   

 

После включения все элементы управления, содержащие подсказку, начнут отображать ее, как только элемент управления получит фокус клавиатуры. Подсказка может быть отклонена с течением времени или при изменении фокуса клавиатуры. Пользователи также могут отклонить всплывающую подсказку вручную с помощью сочетания клавиш Ctrl + Shift + F10. Как только всплывающая подсказка будет отклонена, ее можно снова отобразить с помощью того же сочетания клавиш.

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

WPF - Добавлена поддержка свойств SizeOfSet и PositionInSet UIAutomation

Windows 10 представила новые свойства UIAutomation SizeOfSet и PositionInSet, которые используются приложениями для описания количества элементов в наборе. Клиентские приложения UIAutomation, такие как программы чтения с экрана, могут затем запросить приложение для этих свойств и объявить точное представление пользовательского интерфейса приложения.

Эта функция добавляет поддержку WPF приложений для предоставления этих двух свойств UIAutomation. Это может быть выполнено двумя способами:

1. DependencyProperties

Новые DependencyProperties SizeOfSet и PositionInSet были добавлены в пространство имен System.Windows.Automation.AutomationProperties. Разработчик может установить эти значения через XAML:

 

 
 

 

2. Виртуальные методы AutomationPeer

Виртуальные методы GetSizeOfSetCore и GetPositionInSetCore также были добавлены в AutomationPeer класс. Разработчик может предоставить значения для SizeOfSet и PositionInSet, переопределив эти методы:

 

public class MyButtonAutomationPeer : ButtonAutomationPeer 
    { 
        protected override int GetSizeOfSetCore() 
        { 
            // Call into your own logic to provide a value for SizeOfSet 
            return CalculateSizeOfSet(); 
        } 
         protected override int GetPositionInSetCore() 
        { 
            // Call into your own logic to provide a value for PositionInSet 
            return CalculatePositionInSet(); 
        } 
    }

 

Автоматические значения

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

Автоматические значения предоставляются только в том случае, если разработчик нацелен на .NET Framework 4.8 или установил AppContext переключатель «Switch.UseLegacyAccessibilityFeatures.3» - например, через App.config файл:

 
 
      
         
     
   
     
  
В заключение

Попробуйте эти улучшения в .NET Framework 4.8 и поделитесь Вашими отзывами в комментариях здесь или на GitHub.

Часть 1.

Источник




Posted on 29. May 2019

Анонс .NET Framework 4.8. Часть 1

Недавно был выпущен .NET Framework 4.8. Он входит в Windows 10 May 2019 Update. .NET Framework 4.8 также доступен на Windows 7+ и Windows Server 2008 R2+.

Вы можете установить .NET 4.8 на сайте .NET Download. Для сборки приложений, ориентированных на .NET Framework 4.8, Вы можете скачать NET 4.8 Developer Pack. Если Вам нужна среда выполнения .NET 4.8, Вы можете попробовать:

  • .NET 4.8 Web Installer – требует подключение к Интернету во время установки
  • .NET 4.8 Offline installer – может быть загружен и установлен в режиме оффлайн

.NET Framework 4.8 включает в себя обновленный набор инструментов, а также улучшения в нескольких областях:

  • [Runtime] JIT и NGEN улучшения
  • [BCL] Обновленный ZLib
  • [BCL] Уменьшенное FIPS воздействие на криптографию
  • [WinForms] Улучшения доступности
  • [WCF] Улучшенное поведения сервиса
  • [WPF] Усовершенствования с высоким разрешением, улучшения UIAutomation

Вы можете увидеть полный список улучшений в заметках о .NET Framework 4.8 выпуске. Ссылки также были обновлены для .NET 4.8.

Поддерживаемые Windows версии

Windows Client версии: Windows 10 версия 1903, Windows 10 версия 1809, Windows 10 версия 1803, Windows 10 версия 1709, Windows 10 версия 1703, Windows 10 версия 1607, Windows 8.1, Windows 7 SP1

Windows Server версии: Windows Server 2019, Windows Server версии 1803, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows Server 2008 R2 SP1

Новые функции в .NET Framework 4.8

Runtime - JIT улучшения

JIT в .NET 4.8 основан на .NET Core 2.1. Все исправления ошибок и многие улучшения производительности, на основе генерации кода из .NET Core 2.1, теперь доступны в .NET Framework.

Runtime - NGEN улучшения

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

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

Runtime - Сканирование на наличие вредоносного ПО для всех сборок

В предыдущих .NET Framework версиях Windows Defender или другие сторонние программы по защите от вредоносного ПО автоматически сканировали все сборки, загруженные с диска, на наличие вредоносных программ. Однако сборки, загруженные из других источников, например, с использованием Assembly.Load(byte[]), не будут сканироваться и потенциально могут содержать вирусы.

.NET Framework 4.8 на Windows 10 запускает сканирование этих сборок с помощью Windows Defender и многих других решений для защиты от вредоносных программ, в которых реализован интерфейс сканирования на наличие вредоносного ПО. В будущем это усложнит маскировку вредоносного ПО в .NET приложениях.

BCL - Обновленный ZLib

Начиная с .NET Framework 4.5 использовалась нативная ZLib версия (нативная внешняя библиотека сжатия, используемая для сжатия данных) из http://zlib.net в clrcompression.dll, чтобы обеспечить реализацию deflate алгоритма. В .NET Framework 4.8 обновлен clrcompression.dll для использования 1.2.11 версии, которая включает в себя несколько ключевых улучшений и исправлений.

BCL – Уменьшенное FIPS воздействие на криптографию

.NET Framework 2.0+ имеет классы провайдеров криптографии, такие как SHA256Managed, которые генерируют CryptographicException, когда системные криптографические библиотеки настроены в «FIPS режиме». Эти исключения генерируются, потому что управляемые версии не прошли FIPS сертификацию (Федеральные стандарты обработки информации) 140-2 (генерирование JIT и NGEN изображений приведет к аннулированию сертификата), в отличие от системных криптографических библиотек. Лишь немногие разработчики обладают девайсами для разработки в «FIPS режиме», в результате чего эти исключения возникают в процессе сборки (или в системах заказчика). «FIPS режим» также использовался в .NET Framework для блокировки криптографических алгоритмов, которые не считались утвержденными алгоритмами по FIPS правилам.

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

Приложения, нацеленные на .NET Framework 4.8, будут автоматически переключаться на более новую политику и больше не будут видеть исключения, генерируемые из MD5Cng, MD5CryptoServiceProvider, RC2CryptoServiceProvider, RIPEMD160Managed и RijndaelManaged, в «FIPS режиме». Приложения, которые зависят от исключений из предыдущих версий, могут вернуться к предыдущему поведению, установив для AppContext параметра «Switch.System.Security.Cryptography.UseLegacyFipsThrow» значение «true».

Windows Forms - Улучшения доступности

В .NET Framework 4.8 WinForms добавляет три новые функции, которые позволят разработчикам писать более доступные приложения. Добавленные функции предназначены для того, чтобы сделать более надежную передачу данных приложения пользователям с плохим зрением. Была добавлена поддержка всплывающих подсказок, когда пользователь управляет с помощью клавиатуры, были добавлены LiveRegions и Notification Events во многие часто используемые элементы управления.

Чтобы включить эти функции, в Вашем приложении должны быть следующие AppContextSwitches в App.config файле:

Windows Forms - Поддержка UIA LiveRegions в Labels и StatusStrips

UIA Live Regions позволяют разработчикам приложений уведомлять программы чтения с экрана об изменении текста в элементе управления, расположенном отдельно от места, где работает пользователь. Примерами того, где это может пригодиться, может быть StatusStrip, который показывает состояние соединения. Если соединение разорвано и Status изменяется, разработчик может уведомить программу чтения с экрана об этом изменении. В Windows Forms реализованы UIA LiveRegions как для элемента управления Label, так и для элемента управления StatusStrip.

Пример использования LiveRegion в элементе управления Label:

Вы также можете внедрить UserControl в качестве Live региона:

Windows Forms – UIA Уведомления о Событиях

В Windows 10 Fall Creators Update, Windows платформа представила новый метод, позволяющий приложению уведомлять Narrator о том, что содержимое изменилось, и Narrator должен уведомить об этом изменении. UIA уведомление о событии предоставляет Вашему приложению способ вызвать UIA событие, после чего Narrator просто делает объявление на основе текста, который Вы добавляете вместе с событием, без добавления соответствующего элемента управления в Ваш пользовательский интерфейс. В некоторых случаях это значительно улучшает доступность Вашего приложения. Для получения дополнительной информации о UIA Уведомлениях о Событиях, смотрите этот блог пост

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

Пример вызова Уведомления о событии:

Windows Forms - Комбинации доступа с клавиатуры

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

  1. Создайте новое WinForms приложение
  2. Добавьте следующий XML-файл в App.config файл
  3. Добавьте несколько кнопок и элемент управления ToolTip в форму приложения.
  4. Установите подсказки для кнопок.
  5. Запустите приложение и управляйте с помощью клавиатуры:

Windows Forms - Иерархическая структура изменений доступности DataGridView

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

Анонс .NET Framework 4.8. Часть 2

Оригинал



Posted on 22. May 2019

Анонс .NET 5

Хорошие новости - после выхода .NET Core 3.0 планируется выпуск .NET 5. И это будет следующий большой .NET релиз.

Будет только один всеобщий .NET, который Вы сможете использовать на Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и многом другом.

С самого начала существования .NET Core платформы было добавлено около пятидесяти тысяч .NET Framework API. .NET Core 3.0 устранил большую часть оставшихся недоработок в .NET Framework 4.8 функциях, что позволяет использовать Windows Forms, WPF и Entity Framework 6. .NET 5 основывается на этой работе, используя .NET Core и лучшие Mono возможности для создания общей платформы, которую Вы сможете использовать для всего Вашего .NET кода.

В ноябре 2020 года планируется выпуск .NET 5, а первая preview-версия будет доступна в первой половине 2020 года. Она будет поддерживаться в будущих обновлениях для Visual Studio 2019, Visual Studio для Mac и Visual Studio Code.

Изучите .NET Core, чтобы понять, как .NET 5 будет связан с .NET Framework.

.NET 5 = .NET Core vNext

.NET 5 - это следующий шаг .NET Core. Проект нацелен на .NET улучшение несколькими ключевыми способами:

  • Создание единой .NET среды, которая сможет использоваться повсеместно и будет содержать универсальное поведение среды и опыт для разработчиков.
  • Расширенные .NET возможности, которые возьмут только лучшее из .NET Core, .NET Framework, Xamarin и Mono.
  • Создание продукта с помощью единой кодовой базы, над которой разработчики (Microsoft и сообщество) смогут работать и расширять ее общими усилиями, что значительно улучшит все сценарии.
Этот новый проект и направление меняют опыт работы с .NET. В .NET 5 Ваш код и файлы проекта будут выглядеть и работать одинаково независимо от того, какой тип приложения Вы создаете. У Вас будет доступ к одним и тем же средам, API и языковым возможностям в каждом приложении. Это предоставит всем новые улучшения производительности, которые создаются в corefx изо дня в день.

Все, что Вы любите в .NET Core, обязательно останется:
  • Открытый исходный код на GitHub, ориентированный на сообщество.
  • Кроссплатформенная реализация.
  • Поддержка использования специфичных для платформы опций, таких как Windows Forms и WPF на Windows, и личных привязок к каждой платформе от Xamarin.
  • Высокая производительность.
  • Параллельная установка.
  • Небольшие файлы проекта (в стиле SDK).
  • Умный интерфейс командной строки (CLI).
  • Visual Studio, Visual Studio для Mac и Visual Studio Code интеграции.
Что будет добавлено:
  • У Вас будет больше выбора во время работы (подробнее об этом ниже).
  • Взаимодействие Java будет доступно на всех платформах.
  • Совместимость Objective-C и Swift будет поддерживаться на нескольких операционных системах.
  • CoreFX будет расширен для поддержки статической .NET компиляции (AOT), меньшего размера и поддержки большего количества операционных систем.
.NET Core 3.0 будет выпущен в сентябре этого года, NET 5 в ноябре 2020 года, а затем планируются основные ежегодные выпуски каждый ноябрь:

Также готовится выпуск 4 версии, чтобы не сбить с толку пользователей .NET Framework, которые уже давно используют 4.x серию. А .NET 5 - это будущее .NET платформы.

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

Опыт работы

Mono - это оригинальная кроссплатформенная .NET реализация. Она создалавась как .NET Framework альтернатива с открытым исходным кодом и перешла на нацеливание на мобильные устройства, так как iOS и Android устройства стали очень популярными. Mono - среда, используемая как часть Xamarin.

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

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

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

Высокая пропускная способность и высокая производительность

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

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

Усилия по ускорению ASP.NET Core работы на основе TechEmpower тестов являются хорошим примером JIT продуктивности и инвестиций в CoreCLR развитие. Наши усилия по .NET Core укреплению для контейнеров также демонстрируют способность среды выполнения динамически адаптироваться к ограниченным средам.

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

Разработчики, которые используют .NET Core или .NET Framework, в основном полагались на JIT. В результате работа будет достаточно похожа.

Для большинства рабочих .NET 5 нагрузок по умолчанию будет использоваться CLCLR среда на JIT основе. Двумя заметными исключениями являются iOS и клиентская версия Blazor (веб-сборка), поскольку обе требуют нативной (AOT) компиляции.

Быстрый запуск, уменьшенное использование пространства и памяти

Mono Project потратил большую часть усилий на добавление поддержки мобильных и игровых приставок. Ключевой функцией и результатом этого проекта является AOT компилятор для .NET, основанный на ведущем в отрасли проекта LLVM компиляторе. Mono AOT компилятор позволяет встроить .NET код в один исполняемый файл с собственным кодом, который работает на компьютере, так же, как C ++ код. AOT-скомпилированные приложения могут эффективно работать в небольших местах и при необходимости меняться пропускной способностью на запуске.

Проект Blazor уже использует Mono AOT. Это будет один из первых проектов по переходу на .NET 5. Он используется как один из сценариев.

Существует два типа AOT решений:
  • решения, которые требуют 100% AOT компиляции.
  • решения, в которых большая часть кода AOT-компилированна, но где JIT-компиляция или интерпретатор доступны и используются для шаблонов кода, которые не взаимодействуют с AOT (например, generics).
Mono AOT поддерживает оба случая. Первый тип AOT-компиляции требует Apple для iOS девайсов и некоторых игровых консолей. Второй вариант является более распространенным, поскольку он предлагает AOT преимущества без каких-либо недостатков.

.NET Native – это AOT компилятор, который используется для Windows UWP приложений, и является примером первого AOT типа, перечисленного выше. В этой реализации ограничены API и .NET возможности, которые Вы можете использовать. И ключевой задачей этого релиза было охватить весь спектр API и .NET шаблонов.

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

Основы и параллели

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

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

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

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

Все .NET 5 приложения будут использовать CoreFX инфраструктуру. В будущем CoreFX будет хорошо работать в тех местах, где он сегодня не используется, в первую очередь в рабочих нагрузках Xamarin и Blazor. Все .NET 5 приложения можно будет собирать с помощью .NET CLI, что гарантирует наличие общих инструментов командной строки для разных проектов.

C# продвинется вперед к .NET 5. Разработчики .NET 5 приложений получат доступ к последней C# версии и ее возможностям.

Начало проекта

Начало этого проекта было положено в Бостоне в 2018 году. Лучшие дизайнеры из .NET команды (Mono / Xamarin и .NET Core), а также из Unity представили различные технические возможности и его архитектурное направление.

Сейчас они работают, как одна большая команда с одной общей целью. С декабря уже есть прогресс в нескольких проектах:
  • Определен минимальный уровень, который определяет уровень управляемого кода времени выполнения <->, с целью создания > 99% общего CoreFX кода.
  • MonoVM теперь может использовать CoreFX и его библиотеки классов.
  • Все CoreFX тесты запускаются на MonoVM, используя CoreFX реализацию.
  • ASP.NET Core 3.0 приложения запускаются с MonoVM.
  • MonoDevelop и Visual Studio для Mac запускаются на CoreCLR.
Переход на одну .NET реализацию поднимает важные вопросы. Какими будут целевые рамки? Останутся ли правила совместимости NuGet пакетов такими же? Какие рабочие нагрузки должны поддерживаться в .NET 5 SDK? Как писать код для конкретной архитектуры? Нужен ли .NET Standard в будущем? Скоро будут опубликованы все ответы на эти вопросы, чтобы Вы смогли ознакомиться с ними и оставить Ваш отзыв.

В заключение

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

Впереди светлое будущее, в котором Вы сможете использовать одни и те же API-интерфейсы и .NET языки для широкого спектра приложений, операционных систем и архитектур. Станет намного проще вносить изменения в конфигурацию сборки, чтобы по-разному создавать приложения: в Visual Studio, Visual Studio для Mac, Visual Studio Code, Azure DevOps или в командной строке.

Смотрите: .NET 5 на Hacker News



Posted on 20. May 2019

ML.NET 1.0

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

https://github.com/dotnet/machinelearning 

Начните работу @ http://dot.net/ml 

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

Изначально ML.NET разрабатывался в рамках Microsoft Research и превратился в важную среду, используемую многими Microsoft продуктами, такими как Windows Defender, Microsoft Office (Проектирование идей для PowerPoint презентаций, Построение диаграмм в Microsoft Excel), Azure Machine Learning, Ключевые факторы влияния PowerBI и многие другие!

После первого выпуска ML.NET, он стал использоваться многими организациями, такими как SigParser (обнаружение спама в электронной почте), William Mullens (классификация юридических вопросов) и Evolution Software (определение уровня влажности лесных орехов). Вы можете ознакомиться с этими и многими другими организациями, которые используют ML.NET, на витрине ML.NET клиентов. Эти пользователи говорят нам, что простота использования ML.NET, возможность повторно использовать .NET навыки и полное сохранение технического стека в .NET являются основными причинами использования ML.NET.

Наряду с выпуском ML.NET 1.0 также были добавлены новые функции preview-версии, такие как автоматизированное машинное обучение (AutoML) и новые инструменты, такие как ML.NET CLI и ML.NET Model Builder, что позволит Вам добавлять модели машинного обучения в Ваши приложения в один клик!

Остальная часть этого поста посвящена новому функционалу.

Основные компоненты ML.NET

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

1. Представление данных
  • Фундаментальные типы данных конвейера ML данных, такие как IDataView – основной тип конвейера данных
  • Читалки для поддержки чтения данных из текстовых файлов с разделителями или IEnumerable объектов
2. Поддержка задач машинного обучения:
  • Бинарная классификация
  • Мультиклассовая классификация
  • Регрессия
  • Ранжирование
  • Обнаружение аномалий
  • Кластеризация
  • Рекомендация (preview)
3. Преобразование данных и индивидуализация
  • Текст
  • Категории
  • Выбор функций
  • Нормализация и обработка пропущенных значений
  • Подделка образов
  • Временные циклы (preview)
  • Поддержка интеграции ONNX и TensorFlow моделей (preview-версия)
4. Другое
  • Модель понимания и объяснимости
  • Пользовательские преобразования
  • Схема операций
  • Поддержка манипулирования наборами данных и перекрестной проверки
Automated Machine Learning (Preview-версия)

На данный момент, начало работы с машинным обучением включает в себя невероятный путь. При создании пользовательских моделей машинного обучения Вы должны выяснить, какую задачу машинного обучения необходимо выбрать для Вашего сценария (например, классификацию или регрессию?), преобразовать Ваши данные в формат, понятный ML алгоритмам (например, текстовые данные -> числовые векторы), и настроить эти ML алгоритмы, чтобы получить лучшую производительность. Если Вы новичок в ML, каждый из этих шагов может быть довольно сложным!

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

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

Вы можете попробовать AutoML в ML.NET в трех форм-факторах, используя ML.NET Model Builder, ML.NET CLI или прямо через API AutoML (примеры смотрите здесь).

Для пользователей, которые не знакомы с машинным обучением, рекомендуется начать с ML.NET Model Builder в Visual Studio и ML.NET CLI на любой поддерживаемой платформе. AutoML API также очень удобен для сценариев, в которых можно создавать модели на лету.

Model Builder (Preview-версия)

Чтобы упростить .NET разработчикам путь по созданию ML моделей, был выпущен ML.NET Model Builder. С помощью ML.NET Model Builder внедрение машинного обучения в Ваши приложения бует доступно в один клик!

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

Узнайте больше о ML.NET Model Builder

На данный момент, Model Builder находится в режиме предварительного просмотра, и Ваши отзывы и замечания будут очень полезными для его будущего развития!

ML.NET CLI (Preview-версия)

ML.NET CLI (интерфейс командной строки) – это еще один новый инструмент, который был недавно выпущен!

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

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

ML.NET CLI – это кросс-платформенная система, которая представляет собой простое дополнение к .NET CLI. Расширение Model Builder Visual Studio также использует ML.NET CLI для предоставления возможностей построителя моделей.

Вы можете установить ML.NET CLI, используя эту команду.

 

dotnet tool install -g mlnet

 

На следующем рисунке показан интерфейс командной строки ML.NET CLI, создающий набор данных для анализа настроений.

 

Узнайте больше о ML.NET CLI

На данный момент ML.NET CLI тоже находится в режиме предварительного просмотра, и Ваш фидбэк будет очень полезным для его дальнейшего развития!

Начните уже сейчас!

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

 

//Step 1. Create a ML Context
var ctx = new MLContext();
 
//Step 2. Read in the input data for model training
IDataView dataReader = ctx.Data
    .LoadFromTextFile(dataPath, hasHeader: true);
 
//Step 3. Build your estimator
IEstimator est = ctx.Transforms.Text
    .FeaturizeText("Features", nameof(SentimentIssue.Text))
    .Append(ctx.BinaryClassification.Trainers
        .LbfgsLogisticRegression("Label", "Features"));
 
//Step 4. Train your Model
ITransformer trainedModel = est.Fit(dataReader);
 
//Step 5. Make predictions using your model
var predictionEngine = ctx.Model
    .CreatePredictionEngine(trainedModel);
 
var sampleStatement = new MyInput { Text = "This is a horrible movie" };
 
var prediction = predictionEngine.Predict(sampleStatement);

 

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

Что будет дальше в ML.NET?

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

  • AutoML для дополнительных ML сценариев
  • Улучшенная поддержка сценариев глубокого обучения
  • Поддержка других источников, таких как SQL Server, CosmosDB, хранилище Azure Blob и других.
  • Масштабирование в Azure для модели обучения и потребления
  • Поддержка дополнительных сценариев и ML функций при использовании Model Builder и CLI
  • Встроенная интеграция для машинного обучения в масштабе с .NET для Apache Spark и ML.NET
  • Новые ML типы в .NET, например DataFrame
Вклад участников

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


Если Вы еще не начали, обязательно попробуйте ML.NET!

Ваше мнение очень важно для ML.NET улучшения и вскоре .NET будет лучшей платформой для машинного обучения.




Posted on 10. May 2019

Улучшенная диагностика в .NET Core 3.0

В .NET Core 3.0 добавлен набор инструментов, которые используют новые функции в .NET среде, что значительно улучшает диагностику и производительность.

Эти функции помогут Вам ответить на некоторые распространенные вопросы диагностики:

  1. Все ли в порядке с моим приложением?
  2. Почему возникает аномальное поведение в моем приложении?
  3. Почему мое приложение падает?

Все ли в порядке с моим приложением?

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

Метрики

Метрики – это данные измерений за определенные промежутки времени. Данные метрик (или временных рядов) позволят Вам наблюдать за состоянием Вашей системы самым лучшим образом. В отличие от .NET Framework на  Windows, .NET Core не отслеживает производительность. Поэтому был добавлен новый способ генерирования метрик в .NET Core с помощью EventCounter API.

EventCounters намного лучше по сравнению с Windows счетчиками производительности, поскольку теперь они используются на всех ОС, где поддерживается .NET Core. Кроме того, в отличие от счетчиков производительности, они также могут использоваться в средах с низким уровнем привилегий (например, при xcopy развертывании). К сожалению, отсутствие такого инструмента, как Performance Monitor (perfmon), затрудняет использование этих метрик в режиме реального времени.

dotnet-counters

В .NET Core 3.0 Preview 5 есть новый инструмент командной строки для наблюдения за метриками, генерируемыми .NET Core Applications в режиме реального времени.

Вы можете установить этот .NET инструмент, выполнив следующую команду.

dotnet tool install —global dotnet-counters —version 1.0.3-preview5.19251.2

 

Для получения подробных инструкций о том, как использовать этот инструмент, перейдите на dotnet-counters readme. Для ознакомления с известными ограничениями dotnet-counters, перейдите на GitHub.

Почему возникает аномальное поведение в моем приложении?

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

Трассировка

Трассировки – это неизменные записи дискретных событий с отметкой времени. Трассировки содержат локальный контекст, который позволяет лучше определить сбой системы. Обычно .NET Framework (и такие фреймворки, как ASP.NET) генерировали диагностические трассировки о своих внутренних компонентах с помощью Event Tracing для Windows (ETW). В .NET Core эти трассировки были прописаны в ETW для Windows и LTTng для Linux.

dotnet-trace

В .NET Core 3.0 Preview 5 каждое .NET Core приложение открывает двойной канал с именем EventPipe (Unix сокет домен именованный pipe на Windows), через который можно отправлять события. На данный момент ведутся работы над протоколом контроллера, dotnet-trace реализует preview-версию этого протокола.

Вы можете установить этот .NET инструмент, выполнив следующую команду

dotnet tool install —global dotnet-trace—version 1.0.3-preview5.19251.2

 

В приведенном выше примере запускается dotnet trace с профилем по умолчанию, который включает аналитику событий ЦПУ и события .NET среды. 

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

В результате запуска dotnet trace Вы получаете .netperf файл. Этот файл содержит события времени выполнения и выборки ЦПУ стеков, которые можно визуализировать в perfview. Следующее обновление Visual Studio (16.1) также добавит поддержку для визуализации этих трассировок.

Если при записи трассировки Вы работаете на X или Linux, Вы можете преобразовать эти .netperf файлы в .speedscope.json файлы, которые можно визуализировать с помощью Speedscope.app.

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

dotnet trace convert

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

Для получения подробных инструкций о том, как использовать этот инструмент, перейдите на dotnet-trace readme. Для ознакомления с известными ограничениями dotnet-trace, перейдите на GitHub.

Почему мое приложение падает?

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

Dump анализ

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

Обычно Вы полагались на операционную систему для получения dump анализа при сбое приложения (например, Windows Error Reporting) или использовали инструмент, такой как procdump, для доступа к dump при выполнении определенных критериев запуска.

До сих пор проблема с захватом dump анализа с помощью .NET на Linux заключалась в том, что захват дампов с помощью gcore или debugger приводил к очень большим сложностям, поскольку существующие инструменты не знали, какие страницы виртуальной памяти обрезать в .NET Core процессе.

Кроме того, было сложно проанализировать эти dump даже после того, как Вы их собрали, поскольку требовалось использовать debugger и настроить его для sos загрузки, debugger расширения для .NET.

dotnet-dump

В 3.0.0-preview5 добавлен новый инструмент, который собирает и анализирует dump процессы как на Windows, так и на Linux. 

dotnet-dump все еще находится в активной разработке, и в таблице ниже показано, какие функции и на каких ОС поддерживаются на данный момент.

  Windows OS X Linux
Collect
✅
❌
✅
Analyze
❌
❌
✅


Вы можете установить этот .NET инструмент, выполнив следующую команду

dotnet tool install —global dotnet-dump —version 1.0.3-preview5.19251.2

После того, как Вы установили dotnet dump, Вы можете записать dump процесс, выполнив следующую команду

sudo $HOME/.dotnet/tools/dotnet-dump collect -p

На Linux полученный dump можно проанализировать, загрузив его с помощью следующей команды

dotnet dump analyze

 

Для получения подробных инструкций о том, как использовать этот инструмент, перейдите на dotnet-dump readme. Для ознакомления с известными ограничениями dotnet-dump, перейдите на GitHub.

В заключение

 

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

 

Источник



Posted on 21. April 2019

Начните разработку на Windows 10 May 2019 Update уже сегодня

Windows 10 SDK для May 2019 Update уже доступен с действующей лицензией! Обновление Windows 10 May 2019 Update (сборка 18362) теперь взаимодействует с Release Preview Windows Insider. Она также называется Windows 10, сборка 1903.

Новые API и функции для разработчиков

Каждое Windows 10 обновление выпускается с новыми API, Вы можете ознакомиться с полным списком нововведений для разработчиков на странице Windows Dev Center. Вот некоторые из самых полезных.

1. XAML Islands версия 1: Эта первая версия содержит множество улучшений по сравнению с preview-выпуском в 1809 сборке. Некоторые из основых моментов: устранение проблем незаполненного пространства во всплывающих окнах, XAML содержимое соответствует уровню DPI хоста, Narrator поддерживает работу с XAML содержимым, разрешает islands в нескольких окнах верхнего уровня в одном потоке, поддержка MRT локализации и загрузка ресурсов, ускорители клавиатуры работают в кросс-фреймворках. Windows Community Toolkit версии 6, которая будет выпущенна в июне, будет включать в себя упаковки для WPF и WinForms.

2. Windows Subsystem для Linux: После того, как была выпущена 1903 версия, Вы можете получить доступ к Linux файлам на Windows, а также попробовать более удобные опции командной строки!

  1. Теперь Вы можете использовать wslconfig.exe команды в wsl.exe
  2. В wsl.exe добавилось несколько новых команд:
  • –user,-u : запуск дистрибутив от имени указанного пользователя
  • –import : импорт дистрибутив в WSL из архива
  • –export : экспорт дистрибутив из WSL в архив
  • –terminate, t : завершение работающих дистрибутив
3. Windows UI Library 2.1: WinUI обладает открытым исходным кодом, и каждый из Вас может ознакомиться подробнее с вариантами решения проблем с файлами, поучавствовать в обсуждении новых функций и даже добавлении кода на странице WinUI GitHub репозитория. В WinUI 2.1 были добавлены новые элементы управления, такие как анимированный визуальный плеер, улучшенная панель меню, подсказки и советы по обучению, ретранслятор предметов и многое другое. Также есть функции, в которых было разрешено множество проблем с доступностью, визуальными и функциональными возможностями, о которых сообщали разработчики. Вам обязательно стоит попробовать использовать WinUI в Ваших UWP приложениях – это лучший способ получить новейшие возможности разработки с Fluent дизайном, элементами управления, а также обладать опцией обратной совместимости с Windows 10 Anniversary Update.

Обновите Вашу среду разработки в два простых шага уже сегодня

Во-первых, необходимо обновить Вашу систему до Windows 10 May 2019 Update, с помощью Release Preview Ring. У команды Insider есть отличный блог пост, в котором Вы узнаете, как попасть в Release Preview Ring. Как только Вы это сделаете, просто зайдите в Visual Studio 2017 или 2019 и стяните новый SDK, и все готово. Когда в конце мая сборка 1903 станет общедоступной, SDK станет дефолтным SDK в Visual Studio.

Текущая версия Windows Insider Release Preview для Windows 10, обновление к сборке 1903:
  1. Запустите установщик или перейдите по ссылке https://www.visualstudio.com/downloads/ и загрузите его.
  2. Перейдите в «Индивидуальные компоненты»
  3. Перейдите в раздел «SDK, библиотеки и фреймворки»
  4. Проверьте «Windows 10 SDK (10.0. 18362)»
  5. Нажмите «Установить»

Когда выйдет полный выпуск May 2019 Update:

  1. Запустите установщик Visual Studio или перейдите по ссылке https://www.visualstudio.com/downloads/ и загрузите его.
  2. Выберите «Разработка на универсальной Windows платформе» в разделе «Рабочие нагрузки», и Windows 10 SDK (10.0.18362) будет включен по умолчанию
  3. Нажмите «Установить»

Еще больше полезных советов

Хотите получить инструменты для разработки C ++ или UWP игр? Убедитесь, что Вы уже выбрали один из этих двух:

  • Инструменты C ++ разработки для универсальной Windows платформы в разделе «Рабочая UWP нагрузка»
  • Десктопная разработка с помощью C ++ Workload и Windows SDK 10 (10.0.18362)
  • Если Вы хотите использовать инструменты универсальной Windows платформы, выберите рабочую нагрузку инструментов для Universal Windows Platform

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

Ваше мнение о Windows 10 May 2019 Update

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

Известная проблема c негативным влиянием

Существует известная проблема, которая негативно влияет на следующий сценарий при обновлении или установке Windows 10 версии 1903. Когда модуль управления памятью ввода-вывода (IOMMU) работает на VMware Hypervisor, любой гость на виртуальной машине (ВМ) клиента или сервера, который использует IOMMU может перестать работать. Типичные сценарии использования включают в себя, когда для гостевой виртуальной машины включены защита на основе виртуализации (VBS) и защита учетных данных Windows.

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

Источник




Posted on 19. April 2019

Вышел Entity Framework Core 3.0 Preview 4

Недавно была выпущена четвертая preview-версия Entity Framework Core 3.0, доступная для NuGet, а также релизы .NET Core 3.0 Preview 4 и ASP.NET Core 3.0 Preview 4. Эта версия рекомендуема к установке для того, чтобы протестировать новый функционал и оценить фундаментальные изменения.

Что нового в EF Core 3.0 Preview 4?

Эта preview-версия содержит более 50 исправлений ошибок и улучшений функционала. Вы можете запросить у трекера проблем полный список исправлений в Preview 4, а также в Preview 3 и Preview 2.

Некоторые из наиболее важных изменений: 

LINQ-запросы больше не анализируются на клиенте

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

Несмотря на то, что все еще возможно восстановить старое поведение, перенастроив оценку клиента так, чтобы он вызывал только предупреждение, все-таки рекомендуется протестировать Ваше приложение с новым значением по умолчанию. Если Вы видите исключения оценки клиента, Вы можете попробовать изменить Ваши запросы, чтобы избежать оценки клиента. Если это не сработает, Вы можете ввести вызовы AsEnumerable() или ToList(), чтобы переключить обработку запроса к клиенту в тех местах, где это возможно. Вы можете использовать необработанные SQL-запросы вместо LINQ, если ни один из этих вариантов не будет работать.

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

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

Среда EF Core больше не является частью ASP.NET Core платформы

Обратите внимание, что это изменение было добавлено еще в Preview 1, но ранее не было представлено.

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

В любой операционной системе, поддерживаемой для .NET Core разработки, Вы можете установить preview-версию, установив провайдер для EF Core 3.0 Preview 4. Например, чтобы установить SQLite провайдер, введите его в командной строке:

$ dotnet add package Microsoft.EntityFrameworkCore.Sqlite -v 3.0.0-preview4.19216.3

Или из Package Manager Console в Visual Studio:

PM> Install-Package Microsoft.EntityFrameworkCore.Sqlite -Version 3.0.0-preview4.19216.3

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

Инструмент dotnet ef больше не является частью .NET Core SDK

Это изменение позволяет поставлять dotnet ef как обычный .NET CLI инструмент, который можно установить как глобальный или локальный инструмент. Например, чтобы иметь возможность управлять миграциями или создавать DbContext, установите dotnet ef как глобальный инструмент и введите следующую команду:

1
$ dotnet tool install --global dotnet-ef --version 3.0.0-preview4.19216.3
Посмотрите подробности фундаментальных изменений, чтобы узнать больше.

Зависимые сущности, совместно использующие таблицы со своими основными сущностями, теперь необязательны

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

Смотрите вопрос #9005 для получения дополнительной информации.

Улучшения образования ключей для базы данных в памяти

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

Для получения дополнительной информации смотрите вопрос #6872.

Отдельные методы для работы с необработанными SQL-запросами в виде простых или интерполированных строк

Существование перегрузок методов, принимающих SQL как простые или интерполированные строки, затрудняло прогнозирование того, какая версия будет использоваться и как будут обрабатываться параметры. Чтобы устранить эту путаницу, были добавлены новые FromSqlRaw, FromSqlInterpolated, ExecuteSqlRaw и ExecuteSqlInterpolated методы. Существующие FromSql и ExecuteSqlCommand методы уже устарели.

Смотрите вопрос #10996 для получения дополнительной информации.

Соединение с базой данных больше не остается открытым, пока не будет удален TransactionScope

Это позволяет EF Core лучше работать с провайдерами баз данных, которые оптимизированы для работы с System.Transactions, такими как SqlClient и Npgsql.

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

Анализатор кода, который обнаруживает использование внутренних API в EF Core

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

EF1001: Microsoft.EntityFrameworkCore.Internal.MethodInfoExtensions – это внутренний API, который поддерживает инфраструктуру Entity Framework Core и не подчиняется темже стандартам совместимости, что и публичные API. Он может быть изменен или удален без предварительного уведомления в любом выпуске.

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

Смотрите вопрос #12104 для получения дополнительной информации.

Улучшена производительность итерации по отслеживаемым объектам с использованием значения .Local

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

Смотрите вопрос #14231 для получения дополнительной информации.

Концепция типов запросов была переименована без ключей

Обратите внимание, что это изменение было добавлено еще в Preview 3, но ранее не было представлено.

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

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

Новая preview-версия Cosmos DB provider для EF Core

Несмотря на то, что это только начало, уже есть прогресс в провайдере последовательных предварительных выпусков EF Core 3.0. Например, новая версия использует преимущества нового SDK Cosmos DB, позволяет настраивать имена свойств, используемых в хранилище, обрабатывает преобразования значений, использует детерминированный подход для генерации ключей и позволяет указать область Azure для использования.

Для получения полной информации см. Список задач Cosmos DB провайдера здесь.

Что дальше?

Как подробно описано в списке новых функций, в версии 3.0 планируется реализация улучшенного LINQ, поддержка Cosmos DB, поддержка функций C# 8.0, таких как обнуляемые ссылочные типы и асинхронные коллекции, обратный инжиниринг представлений базы данных, сущности пакетов свойств и новая EF6 версия, которая может работать на .NET Core.

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

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

И еще немного важной информации о том, что будет добавлено в будущем:

EF Core 3.0 будет ориентирован на .NET Standard 2.1

Изучив несколько вариантов, был сделан вывод, что создание целевого EF Core 3.0 объекта для .NET Standard 2.1 – лучший путь для использования преимуществ новых функций в .NET и C#, таких как интеграция с IAsyncEnumerable. Это совместимо с аналогичными решениями, выпущенными в прошлом году для ASP.NET Core 3.0 и C# 8.0, и позволяет двигаться вперед, не внедряя адаптеры совместимости, которые могут помешать возможности предоставлять новые функции в .NET Core в будущем.

Хотя Preview 4 по-прежнему предназначен для .NET Standard 2.0, для RTM-версии потребуется версия 2.1, и поэтому он не будет совместим с .NET реализациями, которые поддерживают только .NET Standard 2.0, например .NET Framework. Пользователям, которым необходимо запустить EF Core в .NET Framework, следует продолжить использование EF Core 2.1 или 2.2.

EF 6.3 будет ориентирован на .NET Standard 2.1, в дополнение к уже поддерживаемым .NET Framework версиям

Было обнаружено, что API, предлагаемые .NET Standard 2.1, подходят для EF6 поддержки без удаления каких-либо функций времени выполнения. В дополнение к .NET Standard 2.1 пакет NuFet EF 6.3 будет, как обычно, поддерживать .NET Framework 4.0 (без асинхронной поддержки) и .NET Framework 4.5 и выше. В настоящее время будет тестирование и поддержка только EF 6.3, работающего на .NET Framework и .NET Core 3.0. Но нацеливание на .NET Standard 2.1 откроет возможность работы EF 6.3 с другими .NET реализациями, при условии, что они полностью реализуют стандарт и не имеют других ограничений времени выполнения.

Подводя итоги

EF команда хотела бы поблагодарить всех за отзывы и вклад в эту preview-версию. Не забудьте попробовать последние обновления и оставляйте любые отзывы и запросы здесь.