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<T> с именем ArrayBufferWriter<T>, которую можно использовать с 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<ushort> ConvertToVector256UInt16(Vector128<byte>) теперь является Vector256<short> ConvertToVector256Int16(Vector128<byte>).

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

Записи перечисления 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.



Exception: Object reference not set to an instance of an object.
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.

Источник




Exception: Object reference not set to an instance of an object.
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

Оригинал



Exception: Object reference not set to an instance of an object.
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



Exception: Object reference not set to an instance of an object.
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 будет лучшей платформой для машинного обучения.




Exception: Object reference not set to an instance of an object.
Posted on 26. February 2019

.NET Core 1.0 и 1.1 перестанут работать 27 июня 2019 года

.NET Core 1.0 был выпущен 27 июня 2016 года, а .NET Core 1.1 был выпущен 16 ноября 2016 года. .NET Core 1.0 поддерживается в течение трех лет, как LTS-версия. .NET Core 1.1 входит в тот же период времени, что и .NET Core 1.0. .NET Core 1.0 и 1.1 перестанут поддерживаться 27 июня 2019 года, спустя три года после первоначального выпуска .NET Core 1.0.


С 27 июня 2019 года обновления .NET Core больше не будут включать обновленные пакеты или изображения контейнеров для .NET Core 1.0 и 1.1. Вы должны заранее запланировать обновление с .NET Core 1.x до .NET Core 2.1 или 2.2.

Обновление до .NET Core 2.1

Поддерживаемый путь обновления .NET Core 1.x приложений через .NET Core 2.1 или 2.2. Инструкции по обновлению можно найти в этих документах:
Примечание. Документация по переходу с .NET Core 2.0 на 2.1, в равной степени применима к переходу с .NET Core 1.x на 2.1.

.NET Core 2.1 является выпуском долгосрочной поддержки (LTS). Рекомендуется сделать .NET Core 2.1 Вашим новым стандартом для .NET Core разработки, особенно для приложений, которые не часто обновляются.

По состоянию на 1 октября 2018 года .NET Core 2.0 уже вышел из строя. Важно перенести приложения как минимум на .NET Core 2.1.

Политика поддержки Microsoft

У Microsoft есть политика поддержки для .NET Core. Она включает в себя политики для двух типов релизов: LTS и текущего.

.NET Core 1.0, 1.1 и 2.1 - это LTS версии. .NET Core 2.2 - это текущая версия.
  • LTS версии рассчитаны на долгосрочную поддержку. Они включали в себя функции и компоненты, которые были стабилизированы, требуя нескольких обновлений в течение более длительного срока поддержки. Эти версии являются хорошим выбором для размещения приложений, которые Вы не собираетесь обновлять.
  • Основываясь на отзывах, Текущие версии обладают новыми функциями, которые могут перенести будущие изменения. Эти версии станут хорошим выбором для приложений, которые находятся в активной разработке, и предоставят Вам доступ к последним функциям и улучшениям. Вам нужно обновиться к более новым выпускам .NET Core, чтобы оставаться в поддержке.
Оба вида выпусков получают исправления критических ошибок на протяжении всего своего жизненного цикла для обеспечения безопасности, надежности или для добавления поддержки для новых версий операционной системы. Вы должны быть в курсе последних событий, чтобы получить поддержку.

 .NET Core политика жизненного цикла поддерживаемых ОС определяет, какие версии Windows, macOS и Linux поддерживаются для каждого .NET Core выпуска.



Exception: Object reference not set to an instance of an object.
Posted on 28. January 2019

Больше возможностей с шаблонами в C# 8.0

Больше возможностей с образцами в C# 8.0

Вышел второй предварительный просмотр Visual Studio 2019! Наряду с ним были разработаны дополнительные C# 8.0 функции. В основном в данной статье речь пойдет о новых образцах, хотя в конце также будут рассмотрены другие новости и изменения.

Еще больше образцов

Когда в C# 7.0 была добавлена поддержка образцов, Microsoft объявили, что собираются добавить еще больше образцов в большем количестве знаков. Это время настало! Добавляются так называемые рекурсивные образцы, а также более компактная форма оператора switch выражений, называемых (как Вы уже догадались) switch выражениями.

Вот простой пример образцов C# 7.0:

class Point
{
    public int X { get; }
    public int Y { get; }
    public Point(int x, int y) => (X, Y) = (x, y);
    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
}

static string Display(object o)
{
    switch (o)
    {
        case Point p when p.X == 0 && p.Y == 0:
            return "origin";
        case Point p:
            return $"({p.X}, {p.Y})";
        default:
            return "unknown";
    }
}

Switch выражения

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

Поэтому пришло время добавить форму выражения switch. См. пример:

static string Display(object o)
{
    return o switch
    {
        Point p when p.X == 0 && p.Y == 0 => "origin",
        Point p                           => $"({p.X}, {p.Y})",
        _                                 => "unknown"
    };
}

Ниже приведены отличия от switch операторов:

  • Ключевое слово switch – это «infix» между проверенным значением и {...} списком случаев. Это делает данное слово более совместимым с другими выражениями, а также позволяет отличить его визуально от switch оператора.
  • Ключевое слово case и «:» символ для краткости были заменены лямбда-стрелкой =>.
  • Default значение для краткости было заменено _ шаблоном сброса.
  • Атрибуты bodies – это выражения! Результат выбранного атрибута становится результатом switch выражения.

Поскольку выражение должно иметь значение или выдавать исключение, то switch выражение, которое доходит до конца без совпадений, генерирует исключение. Компилятор предупреждает, когда это может произойти, но не заставляет останавливать все switch выражения с помощью catch-all сервиса: ведь Вы знаете лучше!

Теперь, когда Display метод состоит из только одного return оператора, можно упростить его до состояния выражения:

static string Display(object o) => o switch
    {
        Point p when p.X == 0 && p.Y == 0 => "origin",
        Point p                           => $"({p.X}, {p.Y})",
        _                                 => "unknown"
    };

Этот путь более лаконичный и понятный, ведь, как указано выше, именно краткость позволяет форматировать «табличным» способом switch, с шаблонами и телами на одной линии, где => выстроились друг под другом.

Microsoft планирует разрешить использование «,» запятой после последнего кейса в соответствии со всеми другими «разделенными запятыми списками в фигурных скобках» в C#, но во втором предварительном просмотре Visual Studio 2019 осуществить это пока нельзя.

Образцы свойств

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

Обратите внимание, что switch выражение использует Point p тип шаблона (дважды), а также when предложение для добавления дополнительных условий для первого case.

 В C# 8.0 Microsoft добавляет дополнительные необязательные элементы в тип образца, что позволяет самому образцу углубиться в значение сопоставляемого шаблона. Его можно сделать шаблоном свойства, добавив {...}, который содержит вложенные шаблоны, для применения к доступным свойствам или полям значения. Это позволяет переписать switch выражение следующим образом:

static string Display(object o) => o switch
{
    Point { X: 0, Y: 0 }         p => "origin",
    Point { X: var x, Y: var y } p => $"({x}, {y})",
    _                              => "unknown"
};
Оба случая все еще проверяют, что o является Point. В первом случае 0 шаблон константы применяется рекурсивно к X и Y свойствам переменной p, проверяя, есть ли у них это значение. Таким образом, when условие может быть исключено в данном и многих распространенных случаях.

Во втором случае var шаблон применяется к каждому из X и Y. Стоит напомнить, что выполнение var шаблона в C# 7.0 всегда завершается успешно и просто объявляет новую переменную для хранения значения. Таким образом, x и y содержат значения int для p.X и p.Y.

p никогда не используется, а значит, фактически его можно опустить и здесь:

Point { X: 0, Y: 0 }         => "origin",
    Point { X: var x, Y: var y } => $"({x}, {y})",
    _                            => "unknown"
То, что остается верным для всех типов образцов, включая образцы свойств, – это их ненулевое значение. Благодаря чему становится возможным использование «пустого» {} свойства образца в качестве компактного «ненулевого» шаблона. Например, запасной вариант можно заменить следующими двумя двумя кейсами:

{}                           => o.ToString(),
    null                         => "null"

Позиционные образцы

Образец свойств не совсем укорачивает второй Point кейс, но в данном случае можно сделать многое.

Обратите внимание, что у Point класса есть Deconstruct метод, так называемый deconstructor. В C# 7.0 деконструкторы позволяли деконструировать значение при присваивании, чтобы можно было написать код такого плана:

(int x, int y) = GetPoint(); // split up the Point according to its deconstructor
В C# 7.0 деконструкция с использованием образцов интегрирована не была. Это меняется с позиционными образцами, которые являются дополнительным способом расширения шаблонов типов в C# 8.0. Если совпавший тип является типом кортежа или у него есть деконструктор, то можно использовать позиционные шаблоны как компактный способ применения рекурсивных шаблонов без необходимости называть свойства:

static string Display(object o) => o switch
{
    Point(0, 0)         => "origin",
    Point(var x, var y) => $"({x}, {y})",
    _                   => "unknown"
};

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

Использование деконструкторов не всегда уместно. Их следует добавлять только к тем типам, где значения объяснимы и бесспорны. Например, для Point класса первое значение – X, а второе – Y очевидны, поэтому приведенное выше switch выражение интуитивно понятно и легко читается.

Образцы кортежей

Очень полезный особый случай позиционных образцов – их применение к кортежам. Если switch оператор применяется непосредственно к выражению кортежа, то разрешено опустить дополнительный набор скобок, как в switch (x, y, z) вместо switch ((x, y, z)).

Шаблоны кортежей отлично подходят для одновременного тестирования нескольких входных данных. Ниже приведена простая реализация стейт-машины:

static State ChangeState(State current, Transition transition, bool hasKey) =>
    (current, transition) switch
    {
        (Opened, Close)              => Closed,
        (Closed, Open)               => Opened,
        (Closed, Lock)   when hasKey => Locked,
        (Locked, Unlock) when hasKey => Closed,
        _ => throw new InvalidOperationException($"Invalid transition")
    };

Конечно, можно было бы добавить hasKey во включенный кортеж вместо использования when предложений, но это действительно вопрос вкуса:

static State ChangeState(State current, Transition transition, bool hasKey) =>
    (current, transition, hasKey) switch
    {
        (Opened, Close,  _)    => Closed,
        (Closed, Open,   _)    => Opened,
        (Closed, Lock,   true) => Locked,
        (Locked, Unlock, true) => Closed,
        _ => throw new InvalidOperationException($"Invalid transition")
    };

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

Другие функции C# 8.0 во Втором Предварительном Просмотре

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

Using объявления

В C# using операторы всегда приводят к вложенности, что может сильно раздражать и ухудшать читабельность. Для простых случаев, когда нужно, чтобы ресурс был очищен в конце области, теперь используются using объявления. Using объявления – это объявления локальных переменных с ключевым словом using в начале, где их содержимое располагается в конце текущего блока операторов. Так что вместо:

static void Main(string[] args)
{
    using (var options = Parse(args))
    {
        if (options["verbose"]) { WriteLine("Logging..."); }
        ...
    } // options disposed here
}

Можно написать следующее

static void Main(string[] args)
{
    using var options = Parse(args);
    if (options["verbose"]) { WriteLine("Logging..."); }

} // options disposed here
Disposable ref структуры

Ref Структуры были введены в C# 7.2, полезные функции которых были рассмотрены в других статьях. Стоит отметить, что они накладывают некоторые серьезные ограничения, такие как невозможность реализации интерфейсов. Ref структуры теперь доступны без реализации Idisposable интерфейса, просто с помощью Dispose метода.

Статические локальные функции

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

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

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

Обнуляемые ссылочные типы

Microsoft добавили больше опций для управления пустыми предупреждениями как в источнике (через #nullable и #pragma warning директивы), так и на уровне проекта. Также была изменена подписка на файл проекта к <NullableContextOptions> enable </NullableContextOptions>.

Асинхронные потоки

Microsoft изменила форму IAsyncEnumerable<T> интерфейса, которую ожидает компилятор. Это приводит к тому, что компилятор не синхронизируется с интерфейсом, предусмотренным в .NET Core 3.0 Preview 1, что может привести к некоторым проблемам. Однако планируется выпуск .NET Core 3.0 Preview 2, который вернет синхронизацию интерфейсов.

Обратите внимание

Microsoft ждет Ваших отзывов! Попробуйте новые особенности. 


 




Exception: Object reference not set to an instance of an object.
Posted on 16. January 2019

Выпущены WebRTC UWP и образец callstats.io интеграции

В прошлом году Microsoft объявили о поддержке связи в режиме реального времени на универсальной Windows платформе, которая разработана на развилке Google WebRTC.org репозитория. Проект позволяет UWP разработчикам создавать совместимые с Chrome и похожие по функциям RTC приложения для всех Windows 10 платформ, включая настольные ПК, ноутбуки с HoloLens, Xbox и ARM поддержкой. Интерес общества к проекту увеличивается, о чем говорит 26 тысяч NuGet загрузок и сотни писем от разработчиков на GitHub и на почте. WebRTC и ORTC UWP были значительно улучшены, и Microsoft сообщили о своем вкладе в UWP поддержку репозитория Google WebRTC.org – более подробная информация будет опубликована в ближайшие месяцы.

Однако, постоянно поступает просьба от разработчиков, которые хотят лучше понять качество WebRTC вызовов для своих приложений. Это может быть звонок из HoloLens в десктопный браузер или Xbox приложение потокового видео в реальном времени. С этой целью Microsoft сотрудничает с callstats.io, чтобы обеспечить портативную .NET интеграцию платформы для WebRTC сервисов мониторинга и статистики!

Сегодня Microsoft объявили о выпуске NuGet .NET Standard 2.0 пакета для callstats.io, наряду с образцом кода на основе исходного кода PeerCC UWP. В качестве .NET Standard библиотеки, он доступен для всех поддерживаемых .NET реализаций, включая .NET Framework, .NET Core, UWP, Xamarin и Unity платформы (ознакомьтесь с документацией по требованиям к версии). Образец PeerConnection представляет собой UWP приложение, которое устанавливает двухсторонний видеовызов и отправляет WebRTC статистику в callstats.io службу с 10-секундными интервалами.

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

Kognitiv Spark, лидер в области систем со смешанной реальностью и Windows 10 разработчик, использует callstats.io сервис со своим RemoteSpark приложением.

«Наша операционная команда столкнулась с вопросами, помогающими клиентам решить трудности с сетью, которые могут нарушить сеанс смешанной реальности», – говорит Райан Грум, соучредитель и технический директор Kognitiv Spark. «Благодаря встроенной поддержке Windows 10 мы смогли за несколько часов запустить callstats.io службу и начать использовать полные данные, доступные на ее панели, для обнаружения и решения проблем».

Ознакомьтесь с шагами для интеграции.

1) Создать учетную запись callstats.io.

  • Перейдите по ссылке https://dashboard.callstats.io/register и создайте Организацию.
  • Перейдите на вкладку приложений, чтобы создать приложение, и ввести SDK как другой «UWP».
  • Нажмите на левой боковой панели «Настройки приложения» и перейти на вкладку «Безопасность».
  • Нажмите «Новые учетные данные» и выберите ярлык ключа.
  • Выберите тип ключа как «ECDSA» и введите открытый ключ.
  • Под ключевыми деталями, нажмите на «вид» для учетных данных.
2) Для аутентификации с помощью callstats.io необходимо сгенерировать криптографические ключи и загрузить открытый ключ в сервис. С инструкциями в файле readme.md можно ознакомиться здесь. После выполнения этого шага в проекте должны получиться Config класс и .p12 сертификат. Это все, что необходимо для аутентификации в API REST callstats.io.

3) Перейдите по ссылке на NuGet Org.WebRtc.Callstats пакет, доступный в Вашем проекте здесь.

4) Если используется образец PeerCC, то можно найти классы для сбора данных из PeerCC и WebRTC в Stats папке, также можно использовать этот код в качестве примера для своей реализации. Добавлять файлы из папки PeerCC-Sample репозитория в проект нужно следующим образом:
  • PeerConnectionControllerStateChange.cs: отслеживает RTCPeerConnection изменения состояния и собирает данные о состояниях одноранговых соединений для отправки в callstats.
  • StatsController.cs: собирает данные из всего PeerCC семпла и использует Org.WebRtc.Callstats библиотеку для отправки подготовленных данных в REST API callstats.io.
  • WebRtcStats.cs: подготавливает статистику, полученную из RTCPeerConnection, для связи с callstats.io через REST API.
5) Инициализируйте callstats.io сервис и отправьте SDP и ошибки приложения через StatsController. Для примера, см. Conductor.cs в PeerCC-Sample.

6) Обработайте изменения ICE состояния в RTCPeerConnection и используйте PeerConnectionStateChange для отправки данных на сервис:

_peerConnection.OnIceGatheringStateChange += async() => 
 
            { 
 
                await PeerConnectionStateChange.StatsOnIceGatheringStateChange(_peerConnection); 
 
                Debug.WriteLine("Conductor: Ice connection state change, gathering-state=" + _peerConnection.IceGatheringState.ToString().ToLower()); 
 
            }; 
 
            _peerConnection.OnIceConnectionStateChange += async () => 
 
            { 
 
                if (_peerConnection != null) 
 
                    await PeerConnectionStateChange.StatsOnIceConnectionStateChange(_peerConnection); 
 
                else
 
                { 
                    await PeerConnectionStateChange.PeerConnectionClosedStateChange(); 
 
                    ClosePeerConnection(); 
 
                } 
 
};
7) Отправьте события уровня приложения для отключения и включения звука в StatsController. Для примера см. MainViewModel.cs в PeerCC-Sample.

Теперь образец должен быть полностью подключен к callstats.io сервису и готов к тестированию. Microsoft только начинает улучшать качество вызовов. В дальнейшем работа будет сфокусирована на усовершенствовании взаимодействия с пользователями с помощью дополнительных метрик и AI. Отправляйте Ваши фидбеки об использовании библиотеки, а также отзывы и предложения на GitHub или на email.

 



Exception: Object reference not set to an instance of an object.
Posted on 22. December 2018

Ознакомление с Project Mu

Команда Microsoft Devices Team объявляет о выпуске Project Mu, версии с открытым исходным кодом на базе Unified Extensible Firmware Interface (UEFI) ядра, основанного на Microsoft продуктах, включая Surface и последние версии Hyper-V. UEFI – это системное программное обеспечение, которое инициализирует оборудование во время процесса загрузки и предоставляет сервисы для загрузки операционной системы. Project Mu предоставляет собой множество UEFI функций, предназначенных для современных ПК под управлением Windows. Он также показывает структуру кода и процесс разработки для эффективного использования масштабируемой и надежной прошивки. Эти изменения позволяют Project Mu устройствам поддерживать микропрограмму в виде (FaaS) сервиса. Схожая по своей сути «Windows как сервис», «Прошивка как сервис» оптимизирует UEFI и другие системные прошивки для своевременных исправлений качества, которые обновляют прошивку и обеспечивают эффективную разработку функций сразу после запуска.

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

При первом включении FaaS в Surface было обнаружено, что TianoCore реализация с открытым UEFI исходным кодом не была оптимизирована для быстрого обслуживания для нескольких линейек продуктов. Были проведены несколько итераций продукта на FaaS, а в результате опубликован бесплатный проект с открытым исходным кодом - Project Mu!

Функции проекта

Project Mu включает в себя:

  • Структуру кода и процесс разработки, оптимизированный под прошивку как сервис.
  • Экранную клавиатуру.
  • Безопасное управление UEFI настройками.
  • Повышенную безопасность за счет удаления ненужного устаревшего кода; практика, которая используется для уменьшения зоны атаки.
  • Высокоэффективную загрузку.
  • Примеры современного BIOS меню.
  • Многочисленные тесты и инструменты для анализа и оптимизации качества UEFI.

Материал для ознакомления с документацией и кодом Project Mu Вы найдете по ссылке: https: //microsoft.github.io/mu/ 



Exception: Object reference not set to an instance of an object.
Posted on 3. May 2018

Новое имя UWP Community Toolkit: Windows Community Toolkit

Уже в следующем обновлении UWP Community Toolkit будет переименован на Windows Community Toolkit. Это действительно большой шаг в развитии инструментария и сообщества.

Впервые инструментарий был выпущен более полутора лет назад с 26 различными функциями. С тех пор Microsoft добавили пять новых пакетов в девять новых выпусков, каждый из которых включает в себя новые элементы управления, помощники, службы, расширения, объектные модели и многое другое - большинство из элементов поступает сразу из сообщества. Сегодня существует более 100 различных функций. Вы можете сравнить количество элементов управления (и категорий) на примере приложения с первоначальной версии:

UWP Community Toolkit Sample App (версия 1.0)

UWP Community Toolkit Sample App (версия 2.0)

Когда Microsoft выпустили UWP Community Toolkit, было много отзывов о добавление возможности для разработчиков, поделиться компонентами инструментария с другими инфраструктурами, такими как WPF, WinForms, Xamarin, .NET Core и другими. С помощью сообщества, в версии 2.0 Microsoft идентифицировали компоненты, которые могли быть учтены в библиотеках .NET Standard, и создали новые пакеты .NET Standard для того, чтобы все разработчики могли воспользоваться преимуществами работы сообщества. Сегодня многие из сервисов, помощников и парсеров являются кросс-платформенными и могут использоваться везде. Более того, Microsoft продолжает работать над тем, чтобы добавить еще больше преимуществ.

 

Главная цель сообщества - привлечение большего количества разработчиков, поэтому, начиная со следующей версии Windows Community Toolkit, Microsoft предоставят возможность другим Windows разработчикам, работающим на Windows 10 платформе, использовать все преимущества компонентов инструментария. Таким образом, новое имя привлечет всех Windows разработчиков.

Microsoft с энтузиазмом работает над следующим обновлением инструментария, которое планируется на конец мая. Работа над обновлением доступна для всех, и Microsoft приглашает всех разработчиков принять участие и внести свой вклад. Чтобы начать работу с самым грандиозным обновлением уже сегодня, посетите GitHub репозиторий и погрузитесь в код. Или, если Вы предпочитаете работать с NuGet пакетами, они будут опубликованы для предварительного просмотра в NuGet перед конференцией Microsoft Build. Microsoft будет обновлять документацию и пример приложения одновременно, пожалуйста, обратите внимание, что это пакеты предварительного выпуска, и они могут измениться в окончательной версии. 

Чтобы присоединиться к беседе в Twitter, используйте хэштег #windowstoolkit. Microsoft также будут рады видеть Вас на конференции Microsoft Build 2018!



Exception: Object reference not set to an instance of an object.