Posted on 1. June 2019

Microsoft Web Template Studio

Недавно вышел первый выпуск Microsoft Web Template Studio, кроссплатформенного расширения для Visual Studio Code, которое упрощает и ускоряет создание новых многофункциональных веб-приложений. Команда Web Template Studio значительно упростила создание нового облачного веб-приложения согласно Ваших отзывам и сообщениям на форуме. Web Template Studio предоставляет удобные и простые инструменты для создания Вашего приложения и ReadMe.md файла, который содержит пошаговые инструкции по быстрому началу работы и разработке. Более того, Web Template Studio проект с открытым исходным кодом на GitHub.

Главная задача - предоставить Вам удобный процесс разработки, чтобы Вы не удаляли код и не переписывали все заново. Web Template Studio находится на ранней стадии разработки, но сейчас самое время показать этот выпуск сообществу и получить обширное количество отзывов. Web Template Studio поддерживает один полный путь к приложению через React и Node.js. В будущем будет добавлено много фреймворков, страниц и функций. Если у Вас есть какие-либо пожелания, пожалуйста, сообщите об этом на форуме сообщества. Ваш отзыв очень важен!

Установка

Все очень просто! Зайдите на страницу Visual Studio Marketplace Web Template Studio и нажмите «Установить». Кроме того, Вам также понадобятся Node и Yarn.

Немного о Web Template Studio

Запустите WebTS, используя сочетания клавиш и введите Web Template Studio. Очень просто. Это запустит мастера, и Вы сможете начать создание проекта.

Шаг 1: Название проекта и путь выхода

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

Шаг 2: Тип проекта

После того как Вы назвали проект, выберите тип проекта. На данный момент поддерживается полный стек, но также рассматриваются отдельные страницы и RESTful приложения.

Шаг 3: Фреймворки

Далее, какие фреймворки Вы хотите использовать для внешнего интерфейса и внутреннего интерфейса? На данный момент поддерживается один фреймворк для внешнего интерфейса: React.js и один для внутреннего: Node.js, так как это самая ранняя версия.

Шаг 4: Страницы и облачные службы

Чтобы ускорить создание приложения, Вам предоставляется несколько шаблонов страниц приложения, которые можно использовать для добавления общих страниц пользовательского интерфейса в новое приложение. Текущие шаблоны страниц включают в себя: пустую страницу, общие макеты (например, основные детали) и страницы, которые реализуют общие шаблоны (например, сетка, список). Чтобы сгенерировать эти страницы, добавьте столько страниц, сколько Вам нужно, указав имя для каждой из них. Затем, укажите, какие облачные службы Azure Вы хотите использовать, и платформа для служб включит пометки «TODO». Сейчас  поддерживаемые службы состоят из хранилища (Azure Cosmos DB) и вычисления (функции Azure). В будущем все эти функции будут значительно улучшены.

Шаг 5: Сводка и генерация

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

Шаг 6: Запуск Вашего приложения

Нажмите на ссылку «Открыть проект в VSCode». Вы можете открыть Ваш Readme.MD файл и получить полезные советы и рекомендации, а затем, чтобы запустить веб-сервер. Для запуска React/Node.JS Вам просто нужно открыть терминал, ввести «yarn install», затем «yarn start» и Всё готово! Как видите, веб-приложение - это хорошая отправная точка. Оно извлекает реальные данные, позволяет быстро провести рефакторинг, чтобы Вы могли тратить время на более важные задачи, такие как бизнес-логика.

Ознакомление с будущими функциями

Большая часть тестирования была проведена в WebTS на платформе React с Node.JS, однако экспериментальные версии будут также добавлены для Angular и вскоре в Vue! Если Вы хотите ознакомиться, перейдите в Настройки в коде и включите Preview Mode.

Проект с открытым исходным кодом, созданный с Microsoft Garage Interns

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

Команда Web Template Studio гордится тем, что все это было создано стажерами, принимавшими участие в проекте Microsoft Garage. Garage internship - это уникальная программа для талантливых студентов для работы в группах по 6-8 человек над сложными инженерными проектами. Эта программа преследует три основные цели: сотрудничество, творчество и эксперименты. Этот проект был создан в партнерстве с Microsoft и сообществом. Он прошел через множество вариаций и итераций. Вы можете посмотреть, кто принимал участие здесь.

Начните сегодня

Теперь доступна и темная тема в Web Template Studio. Посмотрите простые инструкции по установке VS расширения на странице GitHub. Не забудьте рассказать о Вашем опыте использования и поделиться оценкой проекта. Вы можете связаться с Клинтом по адресу @clintrutkas уже сейчас!

 

Источник



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-версию. Не забудьте попробовать последние обновления и оставляйте любые отзывы и запросы здесь.





Posted on 17. April 2019

Windows UI Library 2.2

WinUI 2.2 - это последний официальный выпуск Windows UI Library.

Вы можете добавить пакеты WinUI в свое приложение с помощью диспетчера пакетов NuGet: для получения дополнительной информации см. Начало работы с Windows UI Library.

 

WinUI - это проект с открытым исходным кодом, размещенный на GitHub. Мы приветствуем ваши сообщения об ошибках, предложения по улучшению кода в репозитории Windows UI Library.

 

История версий Microsoft.UI.Xaml 2.2

 

Официальный релиз Windows UI Library 2.2

Август 2019

 

Страница выпуска GitHub

Скачать пакет NuGet

 

Новые возможности

 

1)     TabView

Описание:

 

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

 

Документация:

https://docs.microsoft.com/en-us/uwp/api/microsoft.ui.xaml.controls.tabview?view=winui-2.2

 

2)     Обновления NavigationView

 

а) Обновление кнопки “Назад” NavigationView

 

Описание:

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

б) NavigationView - нет автоматического заполнения

 

Описание:

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

Документация:

https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/navigationview#top-whitespace

3)   Обновление Visual Style

а) Corner Radius

Описание:

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

GitHub Ссылка:

https://github.com/microsoft/microsoft-ui-xaml/issues/524

б) Border Thickness

 

Описание:

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

GitHub Spec Ссылка:

https://github.com/microsoft/microsoft-ui-xaml/issues/835

в) кнопка Visual

Описание:

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

GitHub Spec Ссылка:

https://github.com/microsoft/microsoft-ui-xaml/issues/953

г) SplitButton

Описание:

Визуальное отображение SplitButton по умолчанию было обновлено, чтобы сделать его более отчетливым от DropDownButton.

GitHub Spec Ссылка:

https://github.com/microsoft/microsoft-ui-xaml/issues/986

д) ToggleSwitch

Описание:

Ширина ToggleSwitch по умолчанию была уменьшена с 44 до 40 пикселей, поэтому он сбалансирован визуально, сохраняя удобство использования.

GitHub Spec Ссылка:

https://github.com/microsoft/microsoft-ui-xaml/issues/836

 

е) CheckBox и RadioButton

Описание:

Визуальные элементы CheckBox и RadioButton были обновлены, чтобы соответствовать остальной части изменений визуального стиля.

https://github.com/microsoft/microsoft-ui-xaml/issues/839

 

Предварительный релиз Microsoft.UI.Xaml 2.2.190702001

Июль 2019

Страница релиза GitHub

Скачать NuGetпакет загрузки

Экспериментальная особенность

·         TabView

Пререлиз Microsoft.UI.Xaml 2.2.20190416001

Апрель 2019

Страница релиза GitHub

Скачать NuGet пакет загрузки

Экспериментальные особенности

·         FlowLayout

·         LayoutPanel

·         RadioButtons

·         ScrollViewer

 

Источник



Posted on 11. April 2019

Обновления .NET Core в апреле 2019 года - Версии 2.1.10 и 2.2.4

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

.NET Core 2.2.4 и .NET Core SDK 2.2.106 (Загрузить | Примечания к выпуску)

.NET Core 2.1.10 и .NET Core SDK 2.1.506 (Загрузить | Примечания к выпуску)

Безопасность

Уязвимость отказа в обслуживании существует в ASP.NET Core 2.2, где, если приложение размещено на Internet Information Server (IIS), удаленный злоумышленник, не прошедший проверку подлинности, может использовать специально созданный запрос, чтобы вызвать отказ в обслуживании.

Уязвимость затрагивает любые Microsoft ASP.NET Core 2.2 приложения, если они размещены на IIS сервере, на котором запущен AspNetCoreModuleV2 (ANCM), включительно до 12.2.19024.2. Это обновление безопасности устраняет эту уязвимость, обеспечивая предотвращение сбоя рабочего процесса IIS в ответ на специально созданные запросы.

Как получить обновление?

Последние .NET Core обновления доступны на странице загрузки .NET Core.

Смотрите примечания к выпуску .NET Core (2.1.10 | 2.2.4) и узнайте больше об исправленных проблемах и затронутых пакетах.

Docker Изображения

.NET Docker Изображения также обновлены до нынешнего выпуска. Следующие репозитории тоже были обновлены.


Примечание. Посмотрите на «Теги» в каждом репозитории, чтобы увидеть обновленные теги Docker изображений.

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

Развертывание Azure App Services

Развертывание этих обновлений для Azure App Services уже запланировано, и, по текущим оценкам, оно будет завершено к 23 апреля 2019 года.