Visual studio

В марте компания Microsoft выпустила плановые обновления безопасности, закрывающие 82 уязвимости в своих продуктах, 10 из которых были классифицированы каккритические. Среди закрытых уязвимостей 2 являются 0-day и обнародованы публично, а эксплуатация одной из этих уязвимостей была зафиксирована в реальных атаках.

В данной статье я расскажу о самых главных моментах этого выпуска.

Примечание: помимо плановых обновлений в марте был внеплановый выпуск обновлений безопасности для локальных версий Microsoft Exchange Server 2010, 2013, 2016, 2019. Подробности об этом выпуске можно получить в нашемблоге.

Сводная информация по количеству и типу уязвимостей в соответствующих продуктах приведена на графике ниже.

На следующие уязвимости и обновления безопасности следует обратить особое внимание.

Была закрыта критическая уязвимость удаленного исполнения кодаCVE-2021-26867в гипервизоре Microsoft Hyper-V (CVSS 9.9), которой подвержены все последние версии Windows 10 20H2, 2004, 1909 и Windows Server 20H2, 2004, 1909.

Мартовские обновления также исправляют важную уязвимость повышения привилегийCVE-2021-27077в компонентах Windows Win32k (CVSS 7.8). Она была публично раскрыта исследователями из команды Trend Micro Zero Day Initiative. Данная уязвимость затрагивает все поддерживаемые версии Windows и Windows Server.

Отдельного внимание заслуживает закрытая критическая уязвимость удаленного исполнения кодаCVE-2021-26897в службе сервера разрешения сетевых имен Windows DNS (CVSS 9.8). Уязвимости подвержены все поддерживаемые версии Windows Server c 2012 по 2019.

Также обновления затронули важную уязвимость повышения привилегийCVE-2021-24090в функции создания отчетов об ошибках Windows Error Reporting (CVSS 7.8), которой подвержены все последние версии Windows 10 20H2, 2004, 1909 и Windows Server 20H2, 2004, 1909.

Были закрыты сразу 10 уязвимостей в расширении видеокодека HEVC, наиболее интересной из которых является критическая уязвимость удаленного исполнения кодаCVE-2021-24089(CVSS 7.8). Этот компонент не входит по умолчанию в поставку ОС, поэтому данным уязвимостям подвержены только те системы, в которых пользователь или администратор загрузили и установили данное расширение из магазина Microsoft. Причем приложения из магазина Microsoft обновляются автоматически. Подробнее об этом можно узнать изэтойстатьи.

Замыкает команду лидеров мартовского выпуска критическая уязвимость нулевого дня, уже использующаяся в атаках это критическая уязвимость повреждения памятиCVE-2021-26411в браузере Internet Explorer (CVSS 8.8). Данная уязвимость затрагивает версию браузера IE 11. Подробнее об атаках в этойстатье.

Остальные уязвимости были исправлены в компонентах Microsoft Edge (на движке EdgeHTML), Microsoft Office (приложениях и веб-сервисах), SharePoint Server, Visual Studio, VS Code, Azure Kubernetes Service, Azure Container Instance, Azure Spring Cloud, Azure Service Fabric, Azure Sphere и Power BI Report Server.

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

Обновления Servicing Stack Updates (SSU) быливыпущеныдля следующих версий ОС: Windows 10 версии 1809, 1909, 2004, 20H2 и Windows Server версии 2019, 1909, 2004, 20H2.

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

Также хочу напомнить, что в марте заканчивается поддержка браузера Microsoft Edge Legacy (на движке EdgeHTML). Все подробности на нашемпортале.

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

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

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

Помните, почти 90% всех уязвимостей уже имели патчи от производителей на момент обнародования*, и своевременно обновляйте ваши системы.

Артём Синицын CISSP, CCSP, MCSE, MC: Azure Security Engineer
старший руководитель программ информационной безопасности в странах Центральной и Восточной Европы
Microsoft
Twitter YouTube

Microsoft выпустила плановые обновления безопасности, закрывающие 114 уязвимостей, включая 6 уязвимостей в Microsoft Edge и 4 уязвимости в Exchange Server. 19 уязвимостей были классифицированы как Критические и 88 как Важные. Среди закрытых уязвимостей две были обнародованы публично, а эксплуатация одной из этих уязвимостей была зафиксирована в реальных атаках (0-day).

В данной статье я расскажу о самых главных моментах этого выпуска.

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

На следующие уязвимости и обновления безопасности следует обратить особое внимание.

Была закрыта критическая уязвимость удаленного исполнения кода CVE-2021-28329 в компонентах среды исполнения RPC), которой подвержены все поддерживаемые версии Windows и Windows Server. Рейтинг CVSS составил 8.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Апрельские обновления также исправляют важную уязвимость повышения привилегий CVE-2021-28313 в компонентах Windows Diagnostics Hub. Данная уязвимость затрагивает последние версии Windows 10 и Windows Server 20H2, 2004, 1909. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Также была закрыта важная уязвимость повышения привилегий CVE-2021-28347 в компонентах среды исполнения Windows Speech. Уязвимости подвержены все поддерживаемые версии Windows 10. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Устранена важная уязвимость удаленного исполнения кода CVE-2021-27091 в компонентах службы RPC Endpoint Mapper, которая была обнародована публично. Данной уязвимости подвержена только ОС Windows Server 2012. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Также обновления закрывают критическую уязвимость удаленного исполнения кода CVE-2021-27095 в видео-декодере Windows Media, которой подвержены все версии Windows. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Была закрыта важная уязвимость удаленного исполнения кода CVE-2021-28445 в компонентах Windows Network File System (NFS. Данной уязвимости подвержены все ОС Windows кроме Windows 10 и Windows Server 1803. Рейтинг CVSS составил 8.1, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Устранена важная уязвимость удаленного исполнения кода CVE-2021-28451 в приложении Microsoft Excel. Данной уязвимости подвержены Microsoft Office 2019 for Windows/Mac, Microsoft Excel 2013-2016, Microsoft 365 Apps for Enterprise, Microsoft Office Online Server, Microsoft Office Web Apps Server 2013. Рейтинг CVSS составил 7.8, а согласно индексу эксплуатации у атак с использованием данной уязвимости низкий уровень вероятности.

Замыкает команду лидеров апрельского выпуска уязвимость нулевого дня, уже использующуюся в атаках это важная уязвимость повышения привилегий CVE-2021-28310 в компонентах Win32k. Данная уязвимость затрагивает версии Windows 10 и Windows Server 20H2, 2004, 1909, 1809, 1803. Рейтинг CVSS составил 7.8.

Отдельного внимание заслуживают ряд уязвимостей в почтовом сервере Microsoft Exchange. На этот раз затронуты все поддерживаемые версии Exchange Server 2013, 2016, 2019.

Примечание: помимо плановых обновлений в марте был внеплановый выпуск обновлений безопасности для локальных версий Microsoft Exchange Server 2010, 2013, 2016, 2019. Подробности об этом выпуске можно получить в нашем блоге.

Все 4 уязвимости в апрельском выпуске CVE-2021-28480, CVE-2021-28481, CVE-2021-28482, CVE-2021-28483 были классифицированы как Критические, и потенциально позволяют злоумышленнику удаленно выполнить произвольный код на почтовом сервере.

Информация о данных уязвимостях не была обнародована публично и на данный момент не было зафиксировано использование рабочих эксплоитов в реальных атаках. Максимальный рейтинг CVSS среди уязвимостей составил 9.8 из 10 (самый низкий рейтинг 8.8) и согласно индексу эксплуатации у атак с использованием этих уязвимостей высокий уровень вероятности.

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

• Exchange Server 2013 CU23

• Exchange Server 2016 CU19/CU20

• Exchange Server 2019 CU8/CU9

Все подробности вы можете узнать в блоге команды Microsoft Exchange.

Остальные уязвимости были исправлены в компонентах Microsoft Edge (на движке Chromium), Microsoft Office (приложения и веб-сервисы), SharePoint Server, Visual Studio, VS Code, Azure DevOps Server, Azure Sphere, GitHub Pull Requests and Issues Extension и Maven Java Extension.

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

Также хочу напомнить, что в марте закончилась поддержка старой версии браузера Microsoft Edge (на движке EdgeHTML). При установке апрельского накопительного пакета старый браузер будет заменен новой версией Microsoft Edge на движке Chromium. Подробности - в нашем блоге.

Обновления стека обслуживания

Обновления Servicing Stack Updates (SSU) были выпущены для всех поддерживаемых ОС: Windows 10 версии 1809, 1909, 2004, 20H2 и Windows Server версии 2019, 1909.

А для версий 2004, 20H2 обновления SSU теперь поставляются в едином накопительном пакете вместе с остальными обновлениями. О том, как установить сразу и SSU, и обновления безопасности ОС в одном накопительном пакете, автоматически, соблюдая правильную последовательность, читайте в нашем блоге.

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

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

А для того, чтобы быть в курсе самых актуальных новостей информационной безопасности Microsoft, подписывайтесь на канал https://aka.ms/artsin.

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

Автор: Артём Синицын CISSP, CCSP, MCSE, MC: Azure Security Engineer
старший руководитель программ информационной безопасности в странах Центральной и Восточной Европы
Microsoft

Twitter: https://aka.ms/artsin
YouTube: https://aka.ms/artsinvideo

*Vulnerability Review Report by Flexera

ВVSCodeсуществуетнесколькоспособовхранитьнастройкипользователя.Доприходаверсии1.53.0конфиденциальнуюинформациюприходилосьсохранять вMementoобъектахв workspaceState и globalState илинапример keytar. А хранение паролей с токенами в стандартном конфигурационном файле или с помощью переменных окружения, являлось не самой лучшей идеей, так как эти данные могли быть прочитаны и кэшированы другими расширениями.

В статье мы посмотрим на способы чтения данных из settings.json и environment variables. А затем создадим класс с минимальным функционалом, отвечающий за хранение и отдачу ключей со значениями из VSCode SecretStorage.

Проект мы условно назовем fancycolor. Процесс инициализации проекта подробно расписан в документации VSCode Extensions, поэтому сразу приступим к интересному.

settings.json

Все настройки от всех VSCode extensions хранятся в общем файле settings.json и соответственно могут быть доступны из любого расширения. К примеру, из нашего приложения fancycolor мы можем легко прочитать список всех хостов и соответствующие им платформы из нашего конфига другого популярного приложения SSH - Remote.

const configurationWorkspace = workspace.getConfiguration()const sshRemotePlatform: string | undefined = configurationWorkspace.get(  "remote.SSH.remotePlatform")console.log(sshRemotePlatform)

Данный код выведет список вашей конфигурации для расширения SSH - Remote.

Proxy {ubuntu: 'linux', home: 'linux', raspberry: 'linux'}

environment variables

VSCode расширения по умолчанию имеют доступ к переменным окружения пользователя. Все переменные которые вы сохранили в .bashrc в Linux или User.Environment в Windows можно получить с помощью глобального объекта process.env.

Например создадим файл /home/ubuntu/.env с переменной ACCESS_TOKEN_ENV и добавим его в .bashrc.

echo 'export ACCESS_TOKEN_ENV="d8aba3b2-fda0-414a-b867-4798b7892bb4"' >> /home/ubuntu/.envecho "source /home/ubuntu/.env" >> /home/ubuntu/.bashrc

В Windows тоже самое достигается через Powershell.

[System.Environment]::SetEnvironmentVariable('ACCESS_TOKEN_ENV', 'd8aba3b2-fda0-414a-b867-4798b7892bb4', [System.EnvironmentVariableTarget]::User)

Теперь прочитаем его в VSCode fancycolor extension.

import * as process from "process"export const accessTokenEnv = process.env["ACCESS_TOKEN_ENV"]console.log(accessTokenEnv)

В выводе мы видим наш токен.

d8aba3b2-fda0-414a-b867-4798b7892bb4

SecretStorage

На сегодняшний день является лучшим способом хранения паролей, логинов, токенов и другой конфиденциальной информации в VSCode. Для демонстрации создадим простенький класс AuthSettings, где будем хранить fancycolor_token, с минимально необходимыми методами:

• init для инициализации нашего SecretStorage

• getter instance

• storeAuthData для записи в SecretStorage

• getAuthData для извлечения данных из SecretStorage

import { ExtensionContext, SecretStorage } from "vscode"export default class AuthSettings {private static _instance: AuthSettingsconstructor(private secretStorage: SecretStorage) {}static init(context: ExtensionContext): void {/*Create instance of new AuthSettings.*/AuthSettings._instance = new AuthSettings(context.secrets)}static get instance(): AuthSettings {/*Getter of our AuthSettings existing instance.*/return AuthSettings._instance}async storeAuthData(token?: string): Promise<void> {/*Update values in bugout_auth secret storage.*/if (token) {this.secretStorage.store("fancycolor_token", token)}}async getAuthData(): Promise<string | undefined> {/*Retrieve data from secret storage.*/return await this.secretStorage.get("fancycolor_token")}}

В extension.ts напишем функционал позволяющий добавлять и извлекать токен с помощью команд в Command Palette.

import * as vscode from "vscode"import AuthSettings from "./settings"export function activate(context: vscode.ExtensionContext) {// Initialize and get current instance of our Secret StorageAuthSettings.init(context)const settings = AuthSettings.instance// Register commands to save and retrieve tokenvscode.commands.registerCommand("fancycolor.setToken", async () => {const tokenInput = await vscode.window.showInputBox()await settings.storeAuthData(tokenInput)})vscode.commands.registerCommand("fancycolor.getToken", async () => {const tokenOutput = await settings.getAuthData()console.log(tokenOutput)})}export function deactivate() {}

Останется только в package.json зарегистрировать команды fancycolor.setToken и fancycolor.getToken. В последствии при работе с VSCode SecretStorage, мы сможем обратиться исключительно к конкретному SecretStorage созданному для нашего приложения, которому будет присвоен свой _id: 'undefined_publisher.fancycolor'.

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

Начало работы

Чтобы начать работу с новым редактором Razor :

1. Установите последнююVisual Studio preview (16.9 Preview 3).

   • Заметка: Превью-версии Visual Studio можно безопасно устанавоивать вместе со стабильной установкой Visual Studio .

2. ПерейдитеTools>Options>Environment>Preview Featuresи выберите опциюEnable experimental Razor editor:

   

Когда вы собираетесь включить новый редактор Razor, вы можете обнаружить, что он уже включен. Начиная с Visual Studio 16.9 Preview 3, мы постепенно развертываем новый редактор Razor для различных групп пользователей. Если вы опробовали новый редактор ранее, а затем отключили его, вы не будете участвовать в автоматическом внедрении. Вам нужно будет повторно включить его вручную, чтобы увидеть весь прогресс, которого мы достигли. Многие из известных проблем с новым редактором теперь исправлены, поэтому стоит попробовать еще раз, если вы столкнулись с проблемами в более ранних сборках.

Что нового?

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

Улучшенное форматирование

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

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

C# code actions

Некоторые действия кода C# теперь доступны в файлах Razor:

• Добавьте директивы @using или полные имена типов.

• Добавьте null checks.

Дизайн нового редактора Razor значительно упрощает включение действий кода C#, и мы ожидаем, что в будущих выпусках будет доступно гораздо больше.

Переименовывание в закрытых файлах

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

Переименовывание компонентов Blazor

Теперь вы можете переименовать компонент Blazor из его тега. Компонентный файл Razor будет переименован автоматически.

Действия кода компонента

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

• Создать компонент из неизвестного тега.

• Извлечь @code в код программной части.

• Добавить @using для компонентов или полностью квалифицированный тег компонента.

Перейти к определению компонента

Вам нужно быстро увидеть код этого компонента? Просто нажмите F12 на теге, и вы на месте!

Изменение Razor с LiveShare

Новый редактор Razor также работает с LiveShare, поэтому вы получите все новые возможности редактирования Razor даже при работе с Razor в удаленном сеансе.

Используйте новый редактор Razor с Visual Studio Code

Поскольку новый редактор Razor основан на переиспользуемом языковом сервере Razor, новый редактор Razor и его новые функции также доступны в Visual Studio Code с установленным расширением C#.

А как насчет Visual Studio для Mac? Visual Studio для Mac пока не поддерживает LSP, но как только поддержка появится, мы добавим новый редактор Razor в Visual Studio для Mac.

Улучшения подсветки синтаксиса Razor

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

• Razor syntax coloring

• More Razor syntax coloring

Ждем вашу обратную связь

Если у вас возникла проблема с новым редактором, лучший способ сообщить нам об этом - использовать функциюSend Feedback > Report a Problemв Visual Studio.

С выпуском .NET 5 миграция решений из .NET Framework увеличилась. В частности, мы начали наблюдать перемещение очень крупных решений. Чтобы обеспечить максимальное удобство, мы работали над оптимизацией Visual Studio для обработки решений, содержащих большое количество проектов .NET 5 и .NET Core. Многие из этих оптимизаций были включены в версию 16.8, и в этом посте рассматриваются внесенные нами улучшения.

Запуск компилятора C# и VB вне процесса

Roslyn, компилятор C# и Visual Basic, парсит и анализирует все решение для поддержки служб, таких как IntelliSense, Go to Definition и диагностика ошибок. В результате Roslyn имеет тенденцию потреблять ресурсы, которые увеличиваются пропорционально размеру открытого решения, что может стать весьма значительным для больших решений. Команда Roslyn уже работала над минимизацией этого воздействия, активно кэшируя информацию на диске, которая не требуется немедленно, но даже при таком кэшировании нельзя избежать необходимости хранить данные в памяти.

Чтобы уменьшить влияние на более крупные решения Visual Studio, команда Roslyn приложила значительные усилия, чтобы вывести компилятор Roslyn из процесса Visual Studio в его собственный процесс. Запуск Roslyn в собственном процессе освобождает ресурсы в самой Visual Studio и дает компилятору Roslyn больше места для выполнения своей работы. Для больших решений это может сэкономить до трети памяти, потребляемой Visual Studio при открытии большого решения.

Оптимизация узла зависимостей

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

К сожалению, первоначальная реализация узла Dependencies не была очень эффективной в том смысле, что она хранила информацию о переходных зависимостях в памяти. В нем содержалось гораздо больше информации, чем было необходимо, и большая часть данных была избыточной. Мы переписали код, чтобы сохранить только ту информацию, которая абсолютно необходима, и начали использовать существующую информацию о зависимостях, которая уже хранится в NuGet. Эта перезапись сэкономила до 1015% памяти, потребляемой Visual Studio при открытии большого решения.

Уменьшение дублирования информации в MSBuild

После Roslyn одним из других основных потребителей ресурсов в процессе Visual Studio является MSBuild. Это связано с тем, что в качестве механизма сборки большая часть среды IDE основана на объектной модели MSBuild. Хотя мы сделали сами файлы проектов намного меньше в .NET 5 и .NET Core, существует значительное количество вспомогательных файлов проектов, которые импортируются в проекты через SDK. Оценка всех этих файлов необходима для понимания и построения проекта и может потреблять до трети памяти, нужной Visual Studio при открытии большого решения.

Хотя файлы проекта генерируют много данных, большая часть этих данных повторяется, и мы начали дедупликацию этих данных в памяти. Строки - один из наиболее распространенных побочных продуктов системы проектов, и они хранят такую информацию, как имена файлов, параметры и пути. В частности, пути могут быть довольно длинными и потреблять много памяти, если их слишком много или они дублируются слишком много раз. Обеспечено хранение только одной копии строки, что позволяет сэкономить до 510% памяти, потребляемой Visual Studio при открытии большого решения.

Уменьшение количества копий проекта, удерживаемых системой проектов

Одним из важных аспектов проектирования системы проектов .NET 5 и .NET Core является асинхронность. Часто системе проекта требуется выполнять работу в ответ на действие пользователя (например, добавление новой ссылки в проект). Вместо того, чтобы блокировать Visual Studio, пока она завершает свою работу, система проектов позволяет пользователю продолжать работу в среде IDE и выполнять работу в фоновом режиме.

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

Улучшения загрузки большого решения

Проделав всю эту работу, мы значительно оптимизировали работу с большими решениями .NET 5 и .NET Core. Начиная с версии 16.8, во многих наших тестах мы наблюдали увеличение в 2,5 раза размера решения, которое мы можем открыть, прежде чем столкнуться с проблемами ресурсов. Мы также наблюдаем снижение до 25% сбоев, сообщаемых из-за исчерпания ресурсов.

Перечисленные выше улучшения - это только начало изменений, которые мы вносим для улучшения работы с большими решениями в Visual Studio. Производительность отдельных решений по-прежнему может варьироваться в зависимости от размера решения, типа проектов, загруженных расширений и т.д., И есть области, которые мы ищем для улучшения. Мы рекомендуем всем пользователям, у которых возникают проблемы с медленной загрузкой или сбоями при загрузке решений, обращаться к нам по адресу vssolutionload@microsoft.com, чтобы мы могли продолжать улучшать загрузку решений всех типов!

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

Эта статья посвящена разным инструментам, которые можно с той или иной степенью успешности применять для отлова утечек памяти в С++/Qt приложениях (desktop). Инструменты будут рассмотрены в связке с IDE Visual Studio 2019. В статье будут рассмотрены не все возможные инструменты, а лишь наиболее популярные и эффективные.

Наша команда давно и пристально изучает подобные инструменты и использует их в своей работе. Объем кода, на котором есть возможность проверить подобные инструменты, составляет около 1.5 миллиона строк. Опираясь на большой практический опыт, мы расскажем о плюсах и минусах разных инструментов, расскажем, что они способны найти, а что не по зубам, расскажем о неочевидных нюансах и, главное, составим сводную сравнительную таблицу по реальному примеру. Мы постараемся максимально быстро и просто ввести в курс дела (показать быстрый старт), потому даже если ты, читатель, никогда не занимался поиском утечек памяти, эта статья поможет за пару часов разобраться и найти свою первую утечку. Поехали!

В чем проблема?

Утечка памяти ситуация, когда память была выделена (например, оператором new) и ошибочно не была удалена соответствующим оператором/функцией удаления (например, delete).

Пример 1.

int* array = nullptr;for (int i = 0; i < 5; i++){array = new int[10];}delete[] array;

Здесь налицо утечка при выделении памяти для первых 4 массивов. Утекает 160 байт. Последний массив удаляется корректно. Итак, утечка строго в одной строке:

array = new int[10];

Пример 2.

class Test{public:Test(){a = new int[100];b = new int[300];}~Test(){delete[] a;delete[] b;}private:int* a;int* b;};int main(){Test* test = new Test;return 0;}

Здесь утечек уже больше: не удаляется память для a (400 байт), для b (1200 байт) и для test (16 байт для x64). Впрочем, удаление a и b в коде предусмотрено, но его не происходит из-за отсутствия вызова деструктора Test. Таким образом, утечек три, но ошибка, приводящая к этим утечкам, всего одна, и она порождается строкой

Test* test = new Test;

При этом в коде класса Test ошибок нет.

Пример 3.

Пусть есть класс Qt, примерно такой:

class InfoRectangle : public QLabel{Q_OBJECTpublic:InfoRectangle(QWidget* parent = nullptr);private slots:void setInfoTextDelayed();private:QTimer* _textSetTimer;};InfoRectangle::InfoRectangle(QWidget* parent): QLabel(parent){_textSetTimer = new QTimer(this);_textSetTimer->setInterval(50);connect(_textSetTimer, &QTimer::timeout, this, &InfoRectangle::setInfoTextDelayed);}void InfoRectangle::setInfoTextDelayed(){// do anythingsetVisible(true);}

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

InfoRectangle* rectangle = new InfoRectangle();

Будет ли являться это утечкой, если явно не вызван delete? Это зависит от того, включен ли объект в иерархию объектов Qt. Если объект включён одним из следующих примерных вызовов, то нет, не утечка:

mnuLayout->addWidget(rectangle);rectangle->setParent(this);

В остальных же случаях утечка. Причем если мы будем считать точное количество утечек в этом примере, то можем наткнуться на неожиданный вывод: утечек больше, чем можно сначала предположить. Очевидная утечка выделение памяти для InfoRectangle. Побочная утечка выделение памяти для QTimer, несмотря на включение объекта _textSetTimer в иерархию объектов Qt. А вот утечка, которая совсем не очевидна вызов функции connect.

template <typename Func1, typename Func2>    static inline QMetaObject::Connection connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal,                const typename QtPrivate::FunctionPointer<Func2>::Object *receiver, Func2 slot,                Qt::ConnectionType type = Qt::AutoConnection)    {        typedef QtPrivate::FunctionPointer<Func1> SignalType;        typedef QtPrivate::FunctionPointer<Func2> SlotType;        const int *types = nullptr;        if (type == Qt::QueuedConnection || type == Qt::BlockingQueuedConnection)            types = QtPrivate::ConnectionTypes<typename SignalType::Arguments>::types();        return connectImpl(sender, reinterpret_cast<void **>(&signal),                           receiver, reinterpret_cast<void **>(&slot),                           new QtPrivate::QSlotObject<Func2, typename QtPrivate::List_Left<typename SignalType::Arguments, SlotType::ArgumentCount>::Value,                                          typename SignalType::ReturnType>(slot),                            type, types, &SignalType::Object::staticMetaObject);    } 

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

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

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

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

Таблица 1. Эталон поиска утечек памяти.

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

Intel Inspector

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

Установка

Intel Inspector входит в состав пакета Intel Parallel Studio 2019, при этом есть возможность установить только сам Intel Inspector, убрав галочки с остальных компонентов дистрибутива при установке. Visual Studio 2019 должна быть закрыта в момент установки Intel Parallel Studio. После установки, Intel Inspector будет автоматически встроен в Visual Studio и должен появиться на панели инструментов (рис. 1).

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

Запуск

При нажатии на кнопку-значок появится вкладка Intel Inspector с выбором глубины анализа. Выбираем первый пункт Detect Leaks и включаем все галочки, соответствующие всем видам анализа (рис. 2). Если какие-то галочки пропустить, то, к сожалению, есть риск, что не все утечки будут найдены.

Далее нажимаем кнопку Start, через некоторое время откроется приложение. В нем нужно запустить тот или иной сценарий работы, а лучше все сразу (то есть, как следует погонять приложение), затем закрыть. Чем больше на разных параметрах, в разных режимах и в разных сценариях проработает приложение, тем больше утечек памяти будет найдено. И это общий принцип для всех механизмов поиска утечек, использующих динамический анализ. Как мы уточнили ранее, в целях сравнения мы запускали только эталонный сценарий тестирования (см. табл. 1). Итак, после закрытия приложения Intel Inspector слегка задумывается и в итоге выдаёт отчёт следующего вида (рис. 3):

В отчете выдаются кликабельный и сортируемый список утечек, размеры утечек, места в коде с утечками, call-stack и многое другое. Короче, форма выдачи результатов весьма и весьма на уровне. Все очень быстро понимается и усваивается. Все это внутри IDE!

Это будет работать, если есть отладочная информация. То есть debug работать будет, а release нет. В С++-приложениях часто бывает так, что работа в режиме debug намного медленнее, чем в release (мы фиксировали разницу в скорости до 20 раз), и пользоваться debug'ом очень некомфортно. Однако на этот случай есть лайфхак собрать версию release (быструю, со всеми ключами оптимизации), дополнительно включив в нее отладочную информацию. Это позволяет Intel Inspector'у подсветить строки в исходном коде, где он предполагает наличие утечек. О том, как включить в release отладочную информацию, написано здесь.

Результаты

Мы провели сравнение скоростных характеристик работы приложения в разных режимах работы: с Intel Inspector (будем называть его Инспектор) и без него, в debug и release. Тестирование проводилось на эталонном примере (см. табл 1).

Таблица 2. Время тестирования с учётом работы Intel Inspector`а

По таблице можно видеть, что проверка на утечки памяти требует весьма существенного времени. Особенно этот факт начинает играть существенными красками в свете непрерывной интеграции. То есть, если, к примеру, тот сценарий, на котором мы проверяли, включен в состав тестов регрессионного тестирования, то он в них выполняется за 10 секунд. Если же мы захотим на этом же сценарии прогонять поиск утечек памяти (в debug), то это займет примерно в 100 раз больше времени. Прогонять каждую ночь (а тем более, по каждому коммиту) тесты становится невозможно.

Самое главное что можно сказать по качеству найденных утечек? Действительно ли они являются утечками? Нет ли утечек, не замеченных Intel Inspector`ом?

Таблица 3. Результаты работы Intel Inspector

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

Если ликвидировать все такие реальные ошибки, то Intel Inspector все равно будет показывать еще немало утечек, и все они ложные. Более того, по таблице видно, что этих ложных срабатываний в release больше, чем в debug. И в этом случае, судя по всему, сработала оптимизация при компиляции она скрыла от Инспектора некоторые детали, и Инспектор запутался.

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

Пример 1. Утечки в системных dll.

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

Пример 2. aligned_malloc.

m_pVitData = (VITDEC_DATA*)_aligned_malloc(sizeof(VITDEC_DATA), 16);m_pDcsnBuf = (byte*)_aligned_malloc(64 * (VITM6_BUF_LEN + VITM6_MAX_WND_LEN), 16);..._aligned_free(m_pDcsnBuf);_aligned_free(m_pVitData);

К счастью, подобная "утечка" находится только в release, а в debug нет.

Пример 3. Pragma.

#pragma omp parallel for schedule(dynamic)for (int portion = 0; portion < portionsToProcess; ++portion){}

Утечка показывается именно в строке с директивой #pragma!

Возможно, какими-то настройками (внутри Intel Inspector, внутри VS, переменные окружения и т.д.) можно победить этот вал ложных утечек, но из коробки точно нет. Возможно также, что на маленьких и простых приложениях (<50000 строк кода) таких проблем с Intel Inspector не будет. На серьезных же приложениях точно будут, к гадалке не ходи.

Вывод

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

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

Visual Leak Detector

Visual Leak Detector (далее VLD) маленькая библиотека, включаемая в исходный код каждого проекта и выводящая в окно Output (IDE Visual Studio 2019) отчёт по утечкам памяти.

Установка

1. Убедиться, что Visual Studio не запущена.

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

3. Далее установить последний VLD (на момент написания статьи vld-2.5.1-setup.exe) по умолчанию, оставив при установке все галочки включёнными (на добавление в Path и встраивание в Visual Studio). Установщик можно скачать отсюда.

4. На момент написания статьи в дистрибутиве VLD нет нужных dll-файлов для работы с Visual Studio 2019, потому необходимо скопировать dbghelp.dll из папки C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\TestPlatform\Extensions\Cpp\x64 в папку C:\Program Files (x86)\Visual Leak Detector\bin\Win64.

5. Нужно создать заголовочный файл примерно со следующим содержанием:

   #pragma once//#define LEAKS_DETECTION#ifdef LEAKS_DETECTION#include <vld.h>#endif
   

   Как видно, пока что это пустой файл, проверка на утечки памяти в нем выключена.

6. В любой файл реализации (сpp) нужно включить этот новый заголовочник. Это нужно сделать только для одного файла внутри проекта, и для каждого проекта в solution.

Запуск

Достаточно раскомментировать в заголовочном файле строчку

#define LEAKS_DETECTION

и собрать solution. После этого можно запускать (F5) приложение и прогонять разные сценарии, где могут быть утечки памяти. Запускать можно только в конфигурации debug. Release c отладочной информацией работать не будет.

После закрытия проверяемого приложения VLD выведет отчет в окно Output. Отчет содержит список утечек, кликабельный call-stack по каждой утечке, размеры утечек.

---------- Block 652047 at 0x0000000027760070: 8787200 bytes ----------  Leak Hash: 0x02B5C300, Count: 1, Total 8787200 bytes  Call Stack (TID 30996):    ucrtbased.dll!malloc()    d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\heap\new_array.cpp (29): SniperCore.dll!operator new[]()    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\S2Ldfg.cpp (445): SniperCore.dll!CS2Ldfg::CreateLLRTbls() + 0xD bytes    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\S2Ldfg.cpp (217): SniperCore.dll!CS2Ldfg::SetModeEB()    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\S2Ldfg.cpp (1447): SniperCore.dll!CS2Ldfg::Set() + 0xA bytes    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\ddec.cpp (509): SniperCore.dll!DFBase::instanceS2Dec()    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\ddec.cpp (58): SniperCore.dll!DFBase::DFBase() + 0xF bytes    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\ddec\ddec.cpp (514): SniperCore.dll!DgbS5FecAnlzr::DgbS5FecAnlzr() + 0xA bytes    D:\SOURCE\SAP_Git\sap_win64\core\alg\fbg\fbganalyser.cpp (45): SniperCore.dll!TechnicalLayer::FBGAnalyser::FBGAnalyser() + 0x21 bytes    D:\SOURCE\SAP_Git\sap_win64\core\engine\handlers\fbganalysishandler.cpp (218): SniperCore.dll!TechnicalLayer::FBGAnalysisHandler::init() + 0x2A bytes    D:\SOURCE\SAP_Git\sap_win64\core\engine\handlers\fbganalysishandler.cpp (81): SniperCore.dll!TechnicalLayer::FBGAnalysisHandler::enqueueRequest()    D:\SOURCE\SAP_Git\sap_win64\core\engine\threadedhandler2.cpp (57): SniperCore.dll!TotalCore::ThreadedHandler2::run()    Qt5Cored.dll!QTextStream::realNumberPrecision() + 0x89E8E bytes    kernel32.dll!BaseThreadInitThunk() + 0xD bytes    ntdll.dll!RtlUserThreadStart() + 0x1D bytes  Data:    00 00 00 00    01 01 01 01    01 01 01 02    02 02 02 02     ........ ........    02 02 03 03    03 03 03 03    03 04 04 04    04 04 04 04     ........ ........    05 05 05 05    05 05 05 05    06 06 06 06    06 06 06 07     ........ ........    07 07 07 07    07 07 08 08    08 08 08 08    08 09 09 09     ........ ........    09 09 09 09    0A 0A 0A 0A    0A 0A 0A 0B    0B 0B 0B 0B     ........ ........    0B 0B 0C 0C    0C 0C 0C 0C    0C 0D 0D 0D    0D 0D 0D 0D     ........ ........    0E 0E 0E 0E    0E 0E 0E 0E    0F 0F 0F 0F    0F 0F 0F 10     ........ ........    10 10 10 10    10 10 11 11    11 11 11 11    11 12 12 12     ........ ........    EE EE EE EE    EF EF EF EF    EF EF EF F0    F0 F0 F0 F0     ........ ........    F0 F0 F1 F1    F1 F1 F1 F1    F1 F2 F2 F2    F2 F2 F2 F2     ........ ........    F3 F3 F3 F3    F3 F3 F3 F3    F4 F4 F4 F4    F4 F4 F4 F5     ........ ........    F5 F5 F5 F5    F5 F5 F6 F6    F6 F6 F6 F6    F6 F7 F7 F7     ........ ........    F7 F7 F7 F7    F8 F8 F8 F8    F8 F8 F8 F9    F9 F9 F9 F9     ........ ........    F9 F9 FA FA    FA FA FA FA    FA FB FB FB    FB FB FB FB     ........ ........    FC FC FC FC    FC FC FC FC    FD FD FD FD    FD FD FD FE     ........ ........    FE FE FE FE    FE FE FF FF    FF FF FF FF    FF 00 00 00     ........ ........---------- Block 2430410 at 0x000000002E535B70: 48 bytes ----------  Leak Hash: 0x7062B343, Count: 1, Total 48 bytes  Call Stack (TID 26748):    ucrtbased.dll!malloc()    d:\agent\_work\63\s\src\vctools\crt\vcstartup\src\heap\new_scalar.cpp (35): SniperCore.dll!operator new() + 0xA bytes    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\xmemory (78): SniperCore.dll!std::_Default_allocate_traits::_Allocate()    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\xmemory (206): SniperCore.dll!std::_Allocate<16,std::_Default_allocate_traits,0>() + 0xA bytes    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\xmemory (815): SniperCore.dll!std::allocator<TotalCore::TaskResult *>::allocate()    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\vector (744): SniperCore.dll!std::vector<TotalCore::TaskResult *,std::allocator<TotalCore::TaskResult *> >::_Emplace_reallocate<TotalCore::TaskResult * const &>() + 0xF bytes    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\vector (708): SniperCore.dll!std::vector<TotalCore::TaskResult *,std::allocator<TotalCore::TaskResult *> >::emplace_back<TotalCore::TaskResult * const &>() + 0x1F bytes    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include\vector (718): SniperCore.dll!std::vector<TotalCore::TaskResult *,std::allocator<TotalCore::TaskResult *> >::push_back()    D:\SOURCE\SAP_Git\sap_win64\include\core\engine\task.h (119): SniperCore.dll!TotalCore::LongPeriodTask::setTmpResult()    D:\SOURCE\SAP_Git\sap_win64\include\core\engine\discretestephandler.h (95): SniperCore.dll!TotalCore::DiscreteStepHandler::setResult()    D:\SOURCE\SAP_Git\sap_win64\core\engine\handlers\prmbdtcthandler.cpp (760): SniperCore.dll!TechnicalLayer::PrmbDtctHandler::setContResult() + 0x1A bytes    D:\SOURCE\SAP_Git\sap_win64\core\engine\handlers\prmbdtcthandler.cpp (698): SniperCore.dll!TechnicalLayer::PrmbDtctHandler::processPortion()    D:\SOURCE\SAP_Git\sap_win64\core\engine\threadedhandler2.cpp (109): SniperCore.dll!TotalCore::ThreadedHandler2::tryProcess()    D:\SOURCE\SAP_Git\sap_win64\core\engine\threadedhandler2.cpp (66): SniperCore.dll!TotalCore::ThreadedHandler2::run()    Qt5Cored.dll!QTextStream::realNumberPrecision() + 0x89E8E bytes    kernel32.dll!BaseThreadInitThunk() + 0xD bytes    ntdll.dll!RtlUserThreadStart() + 0x1D bytes  Data:    10 03 51 05    00 00 00 00    B0 B4 85 09    00 00 00 00     ..Q..... ........    60 9D B9 08    00 00 00 00    D0 1B 24 06    00 00 00 00     `....... ..$.....    30 B5 4F 11    00 00 00 00    CD CD CD CD    CD CD CD CD     0.O..... ........

В конце отчёта присутствует краткий итог в виде:

Visual Leak Detector detected 383 memory leaks (253257876 bytes).Largest number used: 555564062 bytes.Total allocations: 2432386151 bytes.Visual Leak Detector is now exiting.

Или, если утечек нет,

No memory leaks detected.Visual Leak Detector is now exiting.

Результаты

Мы провели сравнение скоростных характеристик работы приложения в конфигурации debug в разных режимах работы: с VLD и без него. Как было сказано, в конфигурации release (пусть даже и с отладочной информацией) vld работать не может. В табл. 4 замеры времени выполнения для release приводятся исключительно для сравнения с debug. Тестирование проводилось на эталонном примере (см. табл. 1).

Таблица 4. Время тестирования с учётом работы VLD

Что можно сказать по качеству найденных утечек? Действительно ли они являются утечками? Нет ли утечек, не замеченных VLD?

Таблица 5. Результаты работы VLD

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

connect(arrowKeyHandler, &ArrowKeyHandler::upPressed,[this] { selectNeighbourSignal(TopSide); }); 

Потом, разбираясь, оказывается, что деструктор класса всё же не вызывается, и утечка в функции connect действительно есть (см. пример 3). Но поначалу этому списку сложно поверить из-за большой избыточности.

Если ликвидировать все такие реальные ошибки, то VLD честно скажет, что утечек нет. И этот факт крайне важен для continuous integration.

Вывод

Visual Leak Detector штука очень простая и очень полезная, способная найти все утечки (если прогнать все сценарии) и при этом не выдающая ложных срабатываний. Прогон сценариев в VLD довольно медленный, однако, он всё же быстрее, чем в Intel Inspector в конфигурации debug. Плоский, не очень дружественный и простынообразный вывод результатов способен запутать своей объемностью и дубликатами, однако со временем и к нему можно привыкнуть и даже использовать в continuous integration.

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

Снимки оперативной памяти в VS 2019

В IDE Visual Studio 2019 есть собственный встроенный компонент для диагностики проблем Diagnostic Tools. В его составе есть механизм получения снимков памяти (snapshots). С его помощью можно находить утечки памяти как разницу (дельта) между снимками. Само собой, чтобы дельта показывала именно утечки, надо делать снимки в определенные, далеко не случайные моменты.

Запуск

Запустите приложение в отладчике (в конфигурации debug или release c отладочной информацией). При запуске должна по умолчанию появиться панель Diagnostic Tools. Выберите на этой панели вкладку Memory Usage, нажмите кнопку Heap Profiling и дальше делайте снимки кнопкой Take Snapshot.

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

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

Для просмотра результатов нажмём на прирост памяти между снимками (см. Рис. 5, где стрелочка). В появившейся вкладке в области редактора кода выберем ViewMode -> Stacks View (вместо Types View), и через некоторое время формирования отчёта увидим интерактивное дерево вызовов:

Результаты

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

Вывод

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

PVS-Studio

Последняя из рассматриваемых в данной статье утилита, которая может помочь в нахождении утечек памяти, - PVS-Studio. Она делает статический анализ кода, не требующий запуска приложения. Анализ может запускаться и для одного выделенного проекта, и для всех проектов в solution. Также он может запускаться при каждом новом сохранении редактируемого файла исходного кода, инкрементно, сразу указывая на сомнительные места в новом коде.

Установка

Проблем с установкой нет. В результате установки PVS-Studio оказывается встроенной в Visual Studio 2019, в меню Extensions.

Запуск

Для запуска всего solution`а вызываем команду Extensions->PVS-Studio->Check. Результат проверки выдается во вкладке PVS-Studio и содержит список потенциальных ошибок в коде, распределённых по вкладкам с критичностью High, Medium и Low.

Этот объемный результирующий список будет содержать не только утечки памяти, а и все остальные ошибки в коде, что PVS-Studio посчитает ошибками. Чтобы оставить только то, что касается только утечек памяти, нужно фильтровать список по следующим кодам: V599, V680, V689, V701, V772, V773, V1005, V1023 (более подробно см. здесь).

Для фильтрации нужно зайти в настройки Visual Studio в меню Tools -> Options -> PVS-Studio и на вкладке Detectable Errors (C++) выставить нужные галочки, убрав остальные (при этом удобно сначала использовать команду Hide All, а потом уже ставить галочки) Рис. 8. Также нужно убрать галочки из других групп и вкладки Detectable Errors (C#) (выбирая Hide All или Disabled).

Чтобы показать все сообщения с выбранными кодами ошибок, нужно убедиться, что в окне PVS-Studio над сообщениями все кнопки High, Medium и Low включены.

Результаты

Итак, для поиска утечек памяти был запущен анализ на проекте, включающем около 1.5 млн строк кода и 2269 файлов кода. Анализ производился на Intel Core i7 4790K. Конфигурация кода (debug или release) значения не имеет, поскольку анализ статический (если более точно, разница есть из-за условной компиляции, но она непринципиальна).

Таблица 6. Поиск утечек памяти утилитой PVS-Studio

Вывод

Для поиска утечек памяти этой утилитой можно пользоваться только, если под рукой нет чего-то более заточенного под утечки памяти (Intel Inspector, VLD). Она не способна находить все утечки, но выдает ложные срабатывания. Это не удивительно, поскольку утилита PVS-Studio никогда и не заявлялась как специализированный инструмент поиска утечек.

Сравнение работы инструментов для поиска утечек памяти

Подводя итоги, можно однозначно выделить в качестве лучших 2 инструмента для поиска утечек Intel Inspector и Visual Leak Detector. На основании проведенного тестирования мы получаем следующую их сравнительную таблицу:

Таблица7. Сравнение Intel Inspector и VLD.

Место 1 в рейтинге целесообразно отдать VLD, поскольку он не выдает ложных срабатываний, более стабилен в работе и более подходит для использования в сценариях непрерывной интеграции.

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

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

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

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

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

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

Что даёт шаблон микросервиса

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

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

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

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

• Чем меньше времени уходит на лишние действия, тем меньше time-to-market. Релизы поставляются чаще, продукт развивается быстрее.

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

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

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

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

Что фиксируется в шаблоне

1. Структура папок и базовые классы необходимые для любого микросервиса

2. Настройки Rest API, баз данных, авторизации, брокеров сообщений

3. Правильные версии базовых библиотек

4. Наши внутренние наработки и настройки

   • Библиотеки собственной разработки

   • Пайплайны сборки и поставки (CI/CD)

   • То, что называется Observability, а именно логирование, трассировка, health check monitoring

5. Помимо самого кода, мы стандартизуем всю экосистему для нашего будущего микросервиса: настраиваем политики работы Git репозитория, пайплайны Jenkins/Gitlab.

Как выглядит наш шаблон микросервиса для .Net

Наш базовый микросервис является расширением Microsoft Visual Studio и объединяет в себе пять компонентов:

• Web API Project - бэк-сервис, который отвечает на HTTP-запросы.

• Data base project база данных микросервиса.

• HTTP Service client project позволяет вызывать методы в сервисе бэка

• MassTransit consumers project обеспечивает получение сообщений из RabbitMQ.

• Job Project применяется для выполнения каких-либо действий по расписанию.

Модули можно добавить в проект сразу все разом или по отдельности. Выбор сделан на основе простого UI, где достаточно галочками прощёлкать нужные компоненты:

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

Итоги

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

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

Мы рады сообщить, что стал доступен релиз расширения Python для Visual Studio Code от февраля 2021 года. Вы можете загрузить расширение Python из Marketplace или установить его прямо из галереи расширений в Visual Studio Code. Если у вас уже установлено расширение Python, вы также можете получить последнее обновление, перезапустив Visual Studio Code. Вы можете узнать больше о поддержке Python в Visual Studio Code в документации.

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

Обновления расширения Python

Интеграция с TensorBoard

Мы рады запустить интеграцию TensorBoard в VS Code. TensorBoard - это вспомогательный дашборд по анализу данных, который помогает разработчикам PyTorch и TensorFlow визуализировать свои наборы данных и обучение модели. С помощью TensorBoard, непосредственно интегрированного в VS Code, вы можете выборочно проверять прогнозы своих моделей, просматривать архитектуру модели, анализировать потери и точность модели с течением времени, профилировать свой код, чтобы находить узкие места, и многое другое!

Чтобы начать сессию TensorBoard, откройте палитру команд (Ctrl/Cmd + Shift + P) и найдите команду Python: запустить TensorBoard. После этого вам будет предложено выбрать папку, в которой находятся файлы журнала TensorBoard. По умолчанию мы будем использовать ваш текущий рабочий каталог и автоматически обнаружим ваши файлы журнала TensorBoard в любых подкаталогах, но вы также можете указать свой собственный каталог. Затем VS Code откроет новую вкладку с TensorBoard, и ее жизненный цикл также будет управляться VS Code.

Обновления расширения Pylance

Улучшенная читаемость строк документации

Мы рады объявить о значительных улучшениях в "readability" и форматировании строк документации в Pylance. Теперь вы можете более легко читать строки документации с областями с отступом (например, блоки параметров в документах numpy и pandas), вложенные списки (например, в argparse) и модули, использующие форматирование epydoc (например, OpenCV).

Улучшено поведение "go to definition" и "go to declaration"

Мы также улучшили навигацию по коду, чтобы упростить поведение перехода к определению и перехода к описанию и привести вас прямо туда, куда вы хотите. Теперь вместо того, чтобы быть представленным в окне для выбора между типом области (.pyi) или исходным файлом (например, файлы .py), когда оба доступны, переход к определению приведет вас к исходному файлу, а переход к объявлению приведет вас к типу области. Если любой из этих вызовов в противном случае не дал бы никаких результатов (например, перейти к определению, когда доступна только область типа), то Pylance приведет вас к любому доступному файлу, чтобы вы по-прежнему получали некоторую информацию об интересующем символе.

Прочие изменения и улучшения

Мы также добавили небольшие улучшения и исправили проблемы, запрошенные пользователями, которые должны улучшить ваш опыт работы с Python в Visual Studio Code. Заметные изменения включают:

• Минимально необходимая версия VS Code повышена до 1.51.

• Реорганизована команда Enable Linting, чтобы предоставить пользователю возможность выбора Enable или Disable линтинг, чтобы сделать ее более интуитивно понятной.

• Команда Pylance: Report Issue автоматически заполняет новый шаблон GitHub для более простого сообщения об ошибках сервера.

Загрузите расширение Python для Visual Studio Code сейчас, чтобы опробовать вышеуказанные улучшения. Если у вас возникнут какие-либо проблемы или у вас есть предложения, сообщите о проблеме на странице Python VS Code на GitHub.

У меня захватывающие новости - этим летом выйдет первая общедоступная предварительная версия Visual Studio 2022.

Следующий крупный выпуск Visual Studio будет более быстрым, доступным и легким, предназначенным как для учащихся, так и для тех, кто создает решения промышленного масштаба. Впервые Visual Studio будет 64-разрядной. Пользовательский интерфейс будет более чистым, интеллектуальным и ориентированным на действия.

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

Visual Studio 2022: 64-bit

Visual Studio 2022 будет 64-битным приложением, которое больше не будет ограничено ~ 4 ГБ памяти в основном процессе devenv.exe. С помощью 64-разрядной Visual Studio в Windows вы можете открывать, редактировать, запускать и отлаживать даже самые большие и сложные решения, не исчерпывая памяти.

Хотя Visual Studio переходит на 64-разрядную версию, это не меняет типы или разрядность приложений, которые вы создаете с помощью Visual Studio. Visual Studio по-прежнему будет отличным инструментом для создания 32-разрядных приложений.

Мне очень приятно смотреть это видео о масштабировании Visual Studio с целью использования дополнительной памяти, доступной для 64-разрядного процесса, поскольку открывается решение с 1600 проектами и ~ 300к файлов.

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

Дизайн для всех

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

• Обновленные значки для большей четкости, разборчивости и контрастности

• Cascadia Code, новый шрифт фиксированной ширины для лучшей читаемости и поддержки лигатур. (Если хотите, можете попробовать Cascadia Code прямо сейчас!)

• Обновленные и улучшенные темы продуктов

• Интеграция с Accessibility Insights для раннего обнаружения проблем доступности - до того, как они попадут к вашим конечным пользователям.

Персонализация

Как разработчики, мы понимаем, что персонализация вашей IDE так же важна, как и выбор рабочего стула. Мы должны сделать все в самый раз, прежде чем сможем работать максимально продуктивно. Сделать Visual Studio 2022 подходящей для вас будет проще, чем когда-либо, от возможности настраивать аспекты IDE до синхронизации настроек между устройствами для тех, кто поддерживает несколько блоков разработки.

Создание современных приложений

Azure

Visual Studio 2022 позволит быстро и легко создавать современные облачные приложения с Azure. Мы поможем вам начать с большого количества репозиториев, описывающих общие шаблоны, используемые в современных приложениях. Эти репозитории состоят из кода, показывающего эти шаблоны в действии, ресурсов IAAC для предоставления ресурсов Azure, а также предварительно созданных рабочих процессов и действий GitHub, настраивающих вас с помощью полного решения CI/CD при первом создании проекта. Кроме того, в репозитории будет определена необходимая среда разработки, чтобы вы могли сразу приступить к кодингу и отладке.

.NET

Visual Studio 2022 будет иметь полную поддержку .NET 6 и его единой платформы для веб-приложений, клиентских и мобильных приложений для разработчиков как для Windows, так и для Mac. Это включает в себя пользовательский интерфейс многоплатформенного приложения .NET (.NET MAUI) для кроссплатформенных клиентских приложений в Windows, Android, macOS и iOS. Вы также можете использовать веб-технологии ASP.NET Blazor для написания настольных приложений через .NET MAUI.

А для большинства типов приложений, таких как веб-приложения, настольные компьютеры и мобильные устройства, вы сможете использовать .NET Hot Reload для применения изменений кода без необходимости перезапуска или потери состояния приложения.

С++

Visual Studio 2022 будет включать надежную поддержку рабочей нагрузки C++ с новыми функциями повышения производительности, инструментами C++ 20 и IntelliSense. Новые возможности языка C++ 20 упростят управление большими базами кода, а улучшенная диагностика упростит отладку сложных проблем с помощью шаблонов и концепций.

Мы также интегрируем поддержку CMake, Linux и WSL, чтобы упростить вам создание, редактирование, сборку и отладку кроссплатформенных приложений. Если вы хотите перейти на Visual Studio 2022, но беспокоитесь о совместимости, двоичная совместимость со средой выполнения C++ сделает это безболезненным.

Инновации

Диагностика и дебаггинг

Возможность уверенно отлаживать приложения - это центральный элемент вашего повседневного рабочего процесса. Visual Studio 2022 будет включать улучшения производительности в основном отладчике с дополнительными функциями.

Коллаборация в реальном времени

Live Share открывает новые возможности для сотрудничества с другими, обмена идеями, парного программирования и анализа кода. В Visual Studio 2022 Live Share появится интегрированный текстовый чат, чтобы вы могли быстро обсуждать свой код без каких-либо переключений контекста. У вас будет возможность запланировать повторяющиеся сеансы с повторным использованием одной и той же ссылки, что упростит совместную работу с вашими частыми контактами. Чтобы лучше поддерживать Live Share в организациях, мы также представим политики сеансов, которые определяют любые требования соответствия для совместной работы (например, должны ли терминалы чтения/записи быть общими?).

Инсайты и продуктивность

Подсистема AI IntelliCode в Visual Studio продолжает совершенствоваться, легко предвидя ваш следующий шаг. Visual Studio 2022 обеспечит все более глубокую интеграцию в ваши повседневные рабочие процессы, помогая вам предпринимать правильные действия в нужном месте в нужное время.

Асинхронная коллаборация

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

Улучшенный поиск кода

Поиск кода - неотъемлемая часть жизненного цикла разработки программного обеспечения. Разработчики используют поиск кода по множеству причин: учиться у других, делиться кодом, оценивать влияние изменений во время рефакторинга, исследовать проблемы или анализировать изменения. Мы стремимся повысить производительность всех этих критически важных действий в Visual Studio 2022, чтобы ваша продуктивность была еще выше. Вы также сможете искать за пределами загруженной области, чтобы найти то, что ищете, независимо от того, в какой базе кода или репозитории оно находится.

Обновление Visual Studio для Mac

Наша цель в Visual Studio 2022 для Mac - создать современную среду разработки .NET, адаптированную для Mac, которая обеспечит продуктивную работу, которая вам так полюбилась в Visual Studio. Мы работаем над переводом Visual Studio для Mac на собственный пользовательский интерфейс macOS, что означает повышение производительности и надежности. Это также означает, что Visual Studio для Mac может в полной мере использовать все встроенные функции специальных возможностей macOS. Мы обновляем меню и терминологию в среде IDE, чтобы сделать Visual Studio более согласованной между Mac и Windows. Новые возможности Git из Visual Studio также появятся в Visual Studio для Mac, начиная с появления окна инструмента Git Changes.

Поделитесь с нами вашими мыслями

Мы показали вам лишь несколько основных моментов нашей незавершенной работы над Visual Studio 2022. Как всегда, вы можете перейти в новое сообщество разработчиков, чтобы просмотреть существующие запросы функций, проголосовать и комментировать или создать свои собственные.

Следите за новостями о доступности 64-разрядной версии Visual Studio 2022 Preview 1, которая будет включать наши улучшения пользовательского интерфейса и специальные возможности. (И помните! Как и любая другая работа, эти функции все еще находятся в разработке, поэтому некоторые из них появятся в Visual Studio 2022 после первого общедоступного выпуска.)

Спасибо!

Вместе с моим коллегой Евгением мы потратили много времени. Приложение обрабатывает тысячи запросов в асинхронном конвейере, полном async/await. Во время нашего исследования мы получили странные вызовы, они выглядели как бы перевернутыми. Цель этого поста рассказать, почему вызовы могут оказаться перевёрнутыми даже в Visual Studio.

Давайте посмотрим результат профилирования в Visual Studio

Я написал простое приложение .NET Core, которое имитирует несколько вызовов async/await:

static async Task Main(string[] args){    Console.WriteLine($"pid = {Process.GetCurrentProcess().Id}");    Console.WriteLine("press ENTER to start...");    Console.ReadLine();    await ComputeAsync();    Console.WriteLine("press ENTER to exit...");    Console.ReadLine();}private static async Task ComputeAsync(){    await Task.WhenAll(        Compute1(),        ...        Compute1()        ); }

ComputeAsync запускает много задач, выполнения которых будут ожидать другие методы async:

private static async Task Compute1(){    ConsumeCPU();    await Compute2();    ConsumeCPUAfterCompute2();}private static async Task Compute2(){    ConsumeCPU();    await Compute3();    ConsumeCPUAfterCompute3();}private static async Task Compute3(){    await Task.Delay(1000);    ConsumeCPUinCompute3();    Console.WriteLine("DONE");}

В отличие от методов Compute1 и Compute2, последний Compute3 ждёт одну секунду, прежде чем задействовать какие-то ресурсы CPU и вычислить квадратный корень в хелперах CompusumeCPUXXX:

[MethodImpl(MethodImplOptions.NoInlining)]private static void ConsumeCPUinCompute3(){    ConsumeCPU();}[MethodImpl(MethodImplOptions.NoInlining)]private static void ConsumeCPUAfterCompute3(){    ConsumeCPU();}[MethodImpl(MethodImplOptions.NoInlining)]private static void ConsumeCPUAfterCompute2(){    ConsumeCPU();}private static void ConsumeCPU(){    for (int i = 0; i < 1000; i++)        for (int j = 0; j < 1000000; j++)        {            Math.Sqrt((double)j);        }}

В Visual Studio использование ЦП этой тестовой программой профилируется через меню Debug | Performance Profiler....

На панели итоговых результатов (Summary result) нажмите ссылку Open Details....

И выберите древовидное представление стека вызовов.

Вы должны увидеть два пути выполнения:

Если открыть последний из них вы увидите ожидаемую цепочку вызовов:

...если методы были синхронными, что не соответствует действительности. Таким образом, чтобы представить красивый стек вызовов, Visual Studio проделала отличную работу с деталями реализации async/await. Однако если вы откроете первый узел, то получите нечто более тревожное:

... если вы не знаете, как реализованы async/await. Мой код Compute3 определённо не вызывает Compute2, который не вызывает Compute1! Именно здесь реконструкция интеллектуального фрейма/стека вызовов Visual Studio вносит самую большую путаницу. Что же происходит?

Разбираемся с реализацией async/await

Visual Studio скрывает реальные вызовы, но с помощью dotnet-dump и команды pstacks вы сможете увидеть, какие методы на самом деле вызываются:

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

1. Обратный вызов таймера вызывает <Compute3>d__4.MoveNext(), что соответствует концу Task.Delay в методе Compute3.

2. <Compute2>d__3.MoveNext() вызывается после await Compute3, чтобы продолжить выполнение кода.

3. <Compute1>d__.MoveNext() вызывается после await Compute2.

4. ConsumeCPUAfterCompute2() вызывается как ожидалось.

5. ComputeCPU() или ConsumeCPUInCompute3() также вызываются как ожидалось.

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

Все эти типы <имя метода>d__* содержат поля, соответствующие каждому асинхронному методу локальных переменных и параметров, если таковые имеются. Например, вот что генерируется для методов ComputeAsync и Compute1/2/3 async без локальных переменных или параметров:

Поле integer <>1__state отслеживает состояние выполнения машины. К примеру, после создания конечного автомата в Compute1 этому полю присваивается значение -1:

Я не хочу углубляться в детали конструктора, но давайте просто скажем, что метод MoveNext машины состояний <Compute1>d__2 выполняется тем же потоком. Прежде чем рассматривать соответствующую методу Compute1 реализацию MoveNext (без обработки исключений), имейте в виду, что она должна:

1. Выполнить весь код до вызова await.

2. Изменить состояние исполнения (об этом позже).

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

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

5. И делать это до следующего вызова await, снова и снова.

<>1__state равно -1, поэтому выполняется первая "синхронная" часть кода, то есть вызывается метод ComsumeCPU).

Затем для получения соответствующего ожидаемого объекта вызывается метод Compute2 (здесь Task). Если задача выполняется немедленно (т.е. нет вызова await, такого как простая задача . FromResult() в методе async), IsCompleted() вернёт true, и код после вызова await будет выполняться тем же потоком. Да, это означает, что вызовы async/await могут выполняться синхронно одним и тем же потоком: зачем создавать поток, когда он не нужен?

Если задача передаётся в пул потоков для выполнения потоком-воркером, значение <>1__state устанавливается в 0 (поэтому при следующем вызове MoveNext будет выполнена следующая синхронная часть (т.е. после вызова await).

Теперь код вызывает awaitUnsafeOnCompleted, чтобы сотворить магию: добавить продолжение к задаче Compute2 (первый параметр awaiter), чтобы MoveNext был вызван на той же машине состояния (второй параметр this), когда задача завершится. Затем тихо возвращается текущий поток.

Поэтому, когда заканчивается задача Compute2, её продолжение выполняется для вызова MoveNext, на этот раз с <>1__state в значении 0, поэтому выполняются последние две строки: awaiter.GetResult() возвращается немедленно, потому что возвращённая Compute2 Task уже завершена, и теперь вызывается последний метод CinsumeCPUAfterCompute2. Вот краткое описание происходящего:

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

• Каждый раз, когда вы видите вызов await, это означает, что продолжение добавится к задаче Task, обёртывающей выполняемый метод async. Этот код продолжения вызовет метод MoveNext конечного автомата вызывающего метода, чтобы выполнить следующий фрагмент кода, до следующего вызова await.

Вот почему Visual Studio, пытаясь точно сопоставить каждый фрейм состояния асинхронного метода MoveNext исходя из самого метода, показывает перевёрнутые стеки вызовов: фреймы соответствуют продолжениям после вызовов await (зелёным цветом на предыдущем рисунке).

Обратите внимание, что я более подробно описал, как работает async/await, а также действие AwaitUnsageOnCompleted во время сессии на конференции DotNext с Кевином, поэтому не стесняйтесь смотреть запись с этого момента, если вы хотите углубиться в тему.

А если вы хотите погрузиться в C# обратите внимание на наш курс по разработке на этом языке. Универсальный стек среди ваших навыков серьёзно укрепит ваши позиции на рынке труда и увеличит доход.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Привет, Хабр! Сегодня, как и обещали*, делимся подборкой самых интересных для разработчиков конференции Microsoft Build 2021. Их получилось 11, но это не значит, что это все. Чтобы узнать еще больше, изучайте сайт конференции.

* пообещали это мы во вчерашней подборке 8 анонсов конференции Microsoft Build 2021, которую подготовила наша бизнес-команда.

1. Представлен Windows Terminal Preview 1.9

Поздравляем с Microsoft Build 2021 и вторым днем рождения Windows Terminal! Этот выпуск представляет версию 1.9 для Windows Terminal Preview и переносит Windows Terminal в версию 1.8. Как всегда, вы можете установить обе сборки из Microsoft Store, а также со страницы выпусков GitHub.

Среди новинок:

• Дефолтный терминал

• Quake mode

• Обновления Cascadia Code

• Обновления интерфейса настроек

• Другие улучшения

Подробнее здесь.

2. Представляем Visual Studio 2019 v16.10 и v16.11 Preview 1

Мы рады объявить о выпуске Visual Studio 2019 v16.10 GA и v16.11 preview 1. Этот выпуск делает нашу тему продуктивности и удобства разработчиков общедоступной для пользователей Visual Studio! Мы добавили функции C ++ 20, улучшили интеграцию с Git, улучшили инструменты профилирования и множество функций, повышающих продуктивность.

Подробнее здесь.

3. Представляем .NET 6 Preview 4

Мы рады выпустить .NET 6 Preview 4. Мы почти наполовину закончили выпуск .NET 6. Это хороший момент, чтобы еще раз взглянуть на .NET 6 в полном объеме, как и в первом Preview. Многие функции находятся в близкой к окончательной форме, а другие появятся в ближайшее время, когда основные блоки будут готовы к выпуску. Предварительная версия 4 создает прочную основу для выпуска в ноябре финальной сборки .NET 6 с готовыми функциями и возможностями. Она также готова к тестированию в реальных условиях, если вы еще не пробовали .NET 6 в своей среде.

Говоря о финальном выпуске, у нас теперь запланирована дата! Добавьте в календарь даты с 9 по 11 ноября и .NET Conf 2021. Мы выпустим .NET 6 9-го числа с множеством подробных докладов и демонстраций, которые расскажут вам все, что вы хотите знать о .NET 6.

Подробнее здесь.

4. Представляем .NET MAUI Preview 4

Сегодня мы рады объявить о доступности .NET Multi-platform App UI (.NET MAUI) Preview 4. Каждая предварительная версия представляет больше элементов управления и функций для этого многоплатформенного инструментария, который станет общедоступным в ноябре этого года на .NET Conf. .NET MAUI теперь имеет достаточно блоков для создания функциональных приложений для всех поддерживаемых платформ, новые возможности для поддержки запуска Blazor на настольных компьютерах и впечатляющий прогресс в Visual Studio для поддержки .NET MAUI.

Подробнее здесь.

5. Обновления ASP.NET Core в .NET 6 Preview 4

Версия .NET 6 Preview 4 уже доступна и включает много новых крутых улучшений в ASP.NET Core.

Вот что нового в этой предварительной версии:

• Добавлены minimal APIs

• Async streaming

• HTTP logging middleware

• Использование Kestrel для профиля запуска по умолчанию в новых проектах

• IConnectionSocketFeature

• Илучшенные шаблоны single-page app (SPA)

• Обновления .NET Hot Reload

• Ограничения generic type в компонентах Razor

• Blazor error boundaries

• Компиляция Blazor WebAssembly ahead-of-time (AOT)

• Приложения .NET MAUI Blazor

• Другие улучшения производительности

Подробнее здесь.

6. Представляем Entity Framework Core 6.0 Preview 4: Performance Edition

Группа Entity Framework Core анонсировала четвертый предварительный выпуск EF Core 6.0. Основная тема этого выпуска - производительность.

Что нового:

• Производительность EF Core 6.0 теперь на 70% выше в стандартном для отрасли тесте TechEmpower Fortunes по сравнению с 5.0.

• Улучшение производительности полного стека, включая улучшения в тестовом коде, среде выполнения .NET и т. д. Сам EF Core 6.0 на 31% быстрее выполняет запросы.

• Heap allocations уменьшены на43%.

Подробнее здесь.

7. Представляем .NET Hot Reload для редактирования кода во время выполнения

Рады представить вам возможность горячей перезагрузки .NET в Visual Studio 2019 версии 16.11 (предварительная версия 1) и с помощью инструментария командной строки dotnet watch в .NET 6 (предварительная версия 4). В полной статье коллеги познакомят вас с тем, что такое .NET Hot Reload, как вы можете начать использовать эту функцию, каково наше видение будущих запланированных улучшений и проснят, какой тип редактирования и языки в настоящее время поддерживаются.

Подробнее здесь.

8. SecretManagement Module v1.1.0

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

Подробнее здесь.

9. Новый бесплатный курс: создание бессерверных приложений с полным стеком в Azure

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

Подробнее здесь.

10. .NET Framework May 2021

Выпущена предварительная версия накопительного обновления для .NET Framework за май 2021 года.

Подробнее здесь.

11. Представляем сборку OpenJDK от Microsoft

Объявлена общая доступность сборки OpenJDK от Microsoft, нового бесплатного дистрибутива OpenJDK с открытым исходным кодом, доступного бесплатно для всех, с возможностью развертывания его где угодно. Корпорация Майкрософт активно использует Java, внутри компании работает более 500 000 JVM. Группа разработчиков Java очень гордится тем, что вносит свой вклад в экосистему Java и помогает управлять такими рабочими нагрузками, как LinkedIn, Minecraft и Azure!

Сборка включает двоичные файлы для Java 11, основанные на OpenJDK 11.0.11 + 9 x64 server и настольных средах в macOS, Linux и Windows. Мы также публикуем новый двоичный файл раннего доступа для Java 16 для Linux и Windows на ARM, основанный на последней версии OpenJDK 16.0.1 + 9.

Этот новый выпуск Java 16 уже используется миллионами игроков Minecraft с последней версией Minecraft Java Edition Snapshot 21W19A, которая была обновлена для объединения среды выполнения Java 16 на основе сборки Microsoft OpenJDK.

Посетите страницу, чтобы узнать подробности.

Подробнее здесь.

Мы рады сообщить, что стал доступен июньский релиз расширения Jupyter для Visual Studio Code. Если вы работаете с Python, мы рекомендуем загрузить расширение Python из Marketplace или установить его прямо из галереи расширений в Visual Studio Code. Если у вас уже установлено расширение Python, вы также можете получить последнее обновление, перезапустив Visual Studio Code. Узнайте больше о поддержке Python в Visual Studio Code в документации.

В этом релизе основное внимание уделялось:

• Усилению мер безопасности

• Дополнительным настройкам макета Native Notebook

• Улучшению средств Data Viewer и Variable Explorer

Если вам интересно, вы можете изучить полный список улучшений в нашем журнале изменений.

Подробнее о самых интересных новинках под катом.

Workspace Trust

Команда Visual Studio Code серьезно относится к безопасности. Функция Workspace Trust позволяет определить, каким папкам и содержимому проекта вы доверяете, а какие остаются в ограниченном режиме.

Что это значит для notebooks?

При открытии папки в VS Code вас спросят, доверяете ли вы авторам и содержимому папок.

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

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

Дополнительные сведения и сведения о доверии рабочей области см. в разделе Visual Studio Code - доверие рабочей области.

Улучшенная фильтрация в средстве просмотра данных

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

Сортировка в проводнике переменных

По многочисленным просьбам переменные в вашем notebook теперь можно сортировать. Щелкните заголовок Имя или Тип в проводнике переменных для сортировки. Направление стрелки в заголовке будет указывать, по какому заголовку сортируются переменные и в каком порядке выполняется сортировка: в алфавитном или обратном алфавитном порядке.

Новый взгляд на нативные notebooks

Чтобы опробовать нативные notebooks сегодня, загрузите VS Code Insiders и расширение Jupyter. Расширение Python настоятельно рекомендуется для работы с записными книжками Python.

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

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

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

Кастомизируемые нативные notebooks

Хотя приведенные выше основные моменты показывают, что уже работает в notebooks из коробки, вы всегда можете настроить все по своему вкусу. Мы добавили ряд настроек, чтобы по-настоящему сделать ваш notebook идеальным. Чтобы изучить настройки макета notebook, щелкните значок Дополнительные действия в конце панели инструментов и выберите Настроить макет notebook.

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

Полный список настроек компоновки notebook:

• notebook.insertToolbarLocation

• notebook.consolidatedRunButton

• notebook.cellFocusIndicator

• notebook.cellToolbarVisibility

• notebook.compactView

• notebook.consolidatedOutputButton

• notebook.dragAndDropEnabled

• notebook.globalToolbar

• notebook.showCellStatusBar

• notebook.showFoldingControls

• notebook.editorOptionsCustomizations

Прочие изменения и улучшения

Мы также добавили небольшие улучшения и исправили проблемы, запрошенные пользователями, которые должны улучшить ваш опыт работы с notebooks в Visual Studio Code. Некоторые заметные изменения включают:

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

• Добавление ABCMeta и ввод в список исключений проводника переменных

• Настройка размера и вида переменных в соответствии с VS Code

• Скрытие ядер, принадлежащих удаленным средам Python, из средства выбора ядра

Загрузите расширение Python и расширение Jupyter для Visual Studio Code сейчас, чтобы опробовать вышеуказанные улучшения. Если у вас возникнут какие-либо проблемы или у вас есть предложения, сообщите о проблеме на странице Jupyter VS Code GitHub.

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

Я столкнулся с рядом проблем при попытке подключить libpq в VS 2017: начиная с несоответствия документации по данной API с инструкциями по подключению, заканчивая умолчанием некоторых ключевых моментов.

В общем по порядку.

Для использования данного API нужны следующие библиотеки и файлы:

• libpq.dll и libpq.lib - собственно само API Последнее упоминание в документации о возможности сборки ее для Windows находиться в 9й версии. В 10+ этого уже нет. Таким образом проще всего сделать так: ставим postgresql нужной версии и берем оттуда папку PostgreSQL\{номер версии}\lib. Копируем куда нужно и в VS указываем в свойствах проекта Свойства конфигурации>Каталоги VC++> Каталоги библиотек. Далее указываем libpq.lib в Свойства конфигурации>Компоновщик> Ввод >Дополнительные зависимости.

• libpq-fe.h - заголовочный файл для API. В месте со всеми остальными заголовочными файлами находиться в исходниках postgresql. Качаем с офф сайта (https://ftp.postgresql.org/pub/source/v12.0/postgresql-12.0.tar.gz ) нужную версию postgresql. Заголовочные лежат в postgresql-{номер версии}\src\interfaces\libpq. Эту папку подключаем в Свойства конфигурации>Каталоги VC++> Включаемые каталоги. Так же, я подключил сюда и эти каталоги : "\src\include" "\include\libpq" "\src\interfaces" (скажем так, на всякий).

• libintl-8.dll, libiconv-2.dll - лежат в папке с установленным postgres ("PostgreSQL\{номер версии}\bin"). Нужно скопировать в Windows\system32 либо в папку с собранным exe программы.

• libcrypto-1_1-x64.dll, libssl-1_1-x64.dll - библиотеки OpenSSL. Либо ставим его (выбирая при установке, копирование библиотек в папку system32), либо берем эти библиотеки с уже установленного openssl (C:\Program Files\OpenSSL-Win64\bin) и копируем в папку программы или system32 сами.

  Далее еще один момент. В моем случае, платформу проекта пришлось выбрать x64.

  На этом все. Добавляем #include <libpq-fe.h> в программу и работаем

Деревья выражений System.Linq.Expressions дают возможность выразить намерения не только самим кодом, но и его структурой, синтаксисом.

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

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

Это особенно обидно, когда выражение простое, например содержит только доступ к свойству (в библиотеках для маппинга, сериализации, дата-байндинга), вызову конструктора или метода (для IoC/DI решений).

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

Для уменьшения времени получения делегатов из деревьев выражений используют:

• Встроенную интерпретацию.
  Необходимость использования интерпретатора вместо компилятора указывается соответствующим флагом:

  Expression.Compile(preferInterpretation: true)
  

  Происходит через рефлексию, но с накладными расходами на формирование стека инструкций.

  Для платформ Xamarin.iOS, Xamarin.watchOS, Xamarin.tvOS, Mono.PS4 и Mono.XBox стандартная компиляция через генерацию IL (System.Reflection.Emit) долгое время была недоступна и на данный момент под капотом всегда откатывается к этому варианту.

• FastExpressionCompile от @dadhi.
  Ускоряет компиляцию за счет оптимизиpованной генерации IL и с меньшим количеством проверок совместимости.

  На платформах без поддержки JIT компиляции может использоваться только с включенным Mono Interpreter.

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

  Интерпретируя вручную, уже можно воспользоваться способами ускорения рефлексии. Самые эффективные из них, например Fasterflect, используют System.Reflection.Emit и на некоторых платформах так же могут требовать включения Mono Interpreter.

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

Компилировать выражения или какие-то их части во время написания кода (design-time) или сборки (compile-time).

Для compile-time компиляции делегатов к фрагментам деревьев выражений требуется сгенерировать соответствующий код.

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

От самого API требуется только давать нужный делегат по ключу, как в словаре. У интересующих нас фрагментов кода: методов, конструкторов и свойств на стыке run-time и compile-time естественный идентификатор это сигнатура. По ней генерируемый код будет класть делегаты в словарь, а клиенты забирать.

Например, для класса со свойством

namespace Namespace{  public class TestClass  {    public int Property { get; set; }  }}

используемым внутри System.Linq.Expressions.Expression<T> лямбды

Expression<Func<TestClass, int>> expression = o => o.Property;

делегатами чтения и записи в общем виде являются

Func<object, object> _ = obj => ((Namespace.TestClass)obj).Property;Action<object, object> _ => (t, m) => ((Namespace.TestClass)t).Property  = (System.Int32)m;

и генерируемый код для их регистрации будет примерно таким:

namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {      ExpressionDelegates.Accessors.Add("Namespace.TestClass.Property",        getter: obj => ((Namespace.TestClass)obj).Property,        setter: (t, m) => ((Namespace.TestClass)t).Property = (System.Int32)m);    }  }}

Генерация

Наиболее известные решения для кодогенерации, на мой взгляд, это:

• Microsoft.CodeDom,

• T4,

• PostSharp,

• Fody,

• Roslyn Source Generators.

Отдельная область применения есть у каждого решения, и только Roslyn Source Generators умеет анализировать исходный C# код даже в процессе его набора.

Кроме того, именно Roslyn Source Generators видятся более или менее стандартом для кодогенерации, т. к. были представлены как фича основного компилятора языка и используют Roslyn API, используемый в анализаторах и code-fix.

Принцип работы Roslyn Source Generators описан в дизайн-документе (местами не актуален!) и гайде.

Вкратце: для создания генератора требуется создать реализацию интерфейса

namespace Microsoft.CodeAnalysis{  public interface ISourceGenerator  {    void Initialize(GeneratorInitializationContext context);    void Execute(GeneratorExecutionContext context);  }}

и подключить ее к проекту как анализатор.

Метод Initialize пригодится для выполнения какой-либо единоразовой логики. GeneratorInitializationContext на данный момент может быть полезен только для подключения посетителя узлов синтаксиса кода.

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

Для каждого файла исходного кода Roslyn предоставляет синтаксическое дерево в виде объекта SyntaxTree:

GeneratorExecutionContext.Compilation.SyntaxTrees

а так же семантическую модель:

semanticModel =  GeneratorExecutionContext.Compilation.GetSemanticModel(SyntaxTree)

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

Среди всех узлов синтаксических деревьев сборки нам нужно найти только интересующие нас лямбда-выражения типа System.Linq.Expressions.Expression<T> и отобрать из их узлов-потомков выражения, описывающие доступ к членам классов, создание объектов и вызов методов:

По семантике узла, так называемому символу (Symbol), можно определять:

• типы, используемые выражением;

• область видимости;

• IsStatic, IsConst, IsReadOnly и другие характеристики.

На основе такой информации и будем генерировать подходящий код.

В Roslyn API (Microsoft.CodeAnalysis) построить сигнатуру намного проще, чем c API рефлексии (System.Reflection). Достаточно сконвертировать символ в строку при помощи методаISymbol.ToDisplayString(SymbolDisplayFormat) c подходящим форматом:

Зная сигнатуры свойства/поля, его типа и обладателя формируем строки для добавления делегатов:

Оформляем код добавления делегатов в класс и отдаем компилятору:

var sourceBuilder = new StringBuilder(@"namespace ExpressionDelegates.AccessorRegistration{  public static class ModuleInitializer  {    public static void Initialize()    {");      foreach (var line in registrationLines)      {        sourceBuilder.AppendLine();        sourceBuilder.Append(' ', 6).Append(line);      }      sourceBuilder.Append(@"    }  }}");GeneratorExecutionContext.AddSource(  "AccessorRegistration",  SourceText.From(sourceBuilder.ToString(), Encoding.UTF8));

Этот код обязательно будет добавлен в сборку ...если генератор сможет отработать :)

Дело в том, что хоть Source Generators технически и не фича языка, поддерживаются они только в проектах с C# 9+. Позволить такую роскошь без костылей и ограничений на данный момент могут только проекты на .NET 5.

Совместимость

Поддержку Roslyn Source Generators API для .NET Standard, платформ .NET Core, .NET Framework и даже Xamarin поможет организовать Uno.SourceGeneration.

Uno.SourceGeneration предоставляет собственные копии интерфейса ISourceGenerator и атрибута [Generator], которые при миграции на С# 9 меняются на оригинальные из пространства имен Microsoft.CodeAnalysis простым удалением импортов Uno:

using Uno.SourceGeneration;using GeneratorAttribute = Uno.SourceGeneration.GeneratorAttribute;using ISourceGenerator = Uno.SourceGeneration.ISourceGenerator;

<ItemGroup>  <SourceGenerator Include="PATH\TO\GENERATOR.dll" /></ItemGroup>

Инициализация

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

Для этих целей отлично подходит Module Initializer. Это конструктор сборки (а точнее ее модуля), который запускается сразу после ее загрузки и до вызовов к остальному коду. Он давно есть в CLR, но к сожалению, в C# его поддержка c атрибутом [ModuleInitializer] добавлена только в 9 версии.

Решение по добавлению конструктора в сборку с более широкой поддержкой платформ есть у Fody плагин Fody.ModuleInit. После компиляции добавляет классы с именами ModuleInitializer в конструктор сборки. В такой класс и будем оборачивать инициализацию сгенерированных делегатов.

Подключение Fody.ModuleInit через MSBuild свойства вместо FodyWeavers.xml исключит конфликты с другими Weaver-ами Fody в проекте клиента.

Использование

Таким образом, при сборке проекта:

1. Source Generator добавит в сборку код, регистрирующий делегаты для деревьев выражений, в обертке класса ModuleInitializer.

2. Fody.ModuleInit добавит ModuleInitializer в конструктор сборки.

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

Проверяем:

Expression<Func<string, int>> expression = s => s.Length;MemberInfo accessorInfo = ((MemberExpression)expression.Body).Member;Accessor lengthAccessor = ExpressionDelegates.Accessors.Find(accessorInfo);var length = lengthAccessor.Get("17 letters string");// length == 17

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

Бенчмарки

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

Полный вариант таблицы, с бенчмарками интерпретации.

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

Идеи насчёт оптимизации построения сигнатур по System.Reflection.MemberInfo приветствуются. Реализация на момент написания.

Заключение

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

Полный код можно посмотреть на: github/ExpressionDelegates, а подключить через nuget.

Для тех, кто будет пробовать Source Generators хотелось бы отметить несколько полезностей:

• Source Generator Playground (github).
  Позволяет экспериментировать с Roslyn Source Generators в браузере, онлайн.

• Окно визуализации синтаксиса для Visual Studio.
  Удобный инструмент для знакомства с Roslyn Syntax API на собственном коде.

• Отлаживается Source Generator вызовом отладчика из его кода. Пример.
  Для этого нужен компонент Visual Studio Just-In-Time debugger и включенная настройка Tools -> Options -> Debugging -> Just-In-Time Debugging -> Managed.

• В сгенерированных *.cs файлах срабатывают брейкпоинты, проверено в Visual Studio16.8.
  При генерации через Uno.SourceGeneration файлы размещаются по пути: \obj\{configuration}\{platform}\g\.
  С Roslyn Source Generators их появление включается через MSBuild свойство EmitCompilerGeneratedFiles.
  Стандартный путь: \obj\{configuration}\{platform}\generated\, переопределяется в свойстве CompilerGeneratedFilesOutputPath.

• Source Generators можно конфигурировать свойствами MSBuild.
  При использовании Uno.SourceGeneration значение получают вызовом

  GeneratorExecutionContext.GetMSBuildPropertyValue(string)
  

  Для Roslyn Source Generators требуемые свойства необходимо сперва отдельно обозначить в MSBuild группе CompilerVisibleProperty и только после вызывать:

  GeneratorExecutionContext.AnalyzerConfigOptions.GlobalOptions  .TryGetValue("build_property.<PROPERTY_NAME>", out var propertyValue)
  

• Из генератора можно кидать предупреждения и ошибки сборки.

  //Roslyn Source GeneratorsGeneratorExecutionContext.ReportDiagnostic(Diagnostic)//Uno.SourceGeneration:GeneratorExecutionContext.GetLogger().Warn/Error().
  

Сегодня я хочу рассказать вам о таком замечательном инструменте как "dotnet interactive". Я покажу на своём примере как и для чего я начал его использовать, и вкратце опишу с чего начать.

Проблема

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

По итогам протокола считаются различные статистические метрики, которые потом уходят в отчёт. Сейчас формулы, как считать нужную нам статистику, разбросаны по различным этапам ТЗ, поэтому, когда я вчера узнал о "dotnet-interactive" мне сразу пришла мысль о создании notebook'a в формате "Описание метрики"-"Формула"-"Код"-"График", в котором можно будет загрузить любой файл протокола и в интерактивном формате проходить и считать интересующие нас метрики.

Приступаем к созданию notebook'a

Прежде всего, у вас должен быть установлен .net5 sdk и последняя версия VS Code. Далее, нужно лишь установить расширение ".NET Interactive Notebooks". Данное расширение сейчас имеет статус "Preview", однако уже сейчас там можно делать много интересных вещей.

Когда мы установили расширение, можем создать рабочую директорию, в которой будут лежать нужные библиотеки, скрипты и файлы. Открываем её в VS Code и окне команд вбиваем ".NET Interactive: Create new blank notebook" и начинаем наполнять наш notebook.

В первом блоке кода я определил загрузку файла протокола:

#load "Load.fsx"open Loadlet Experiment = loadSep "2021.02.03_15.55.58_gen.sep"

Здесь я на F# подключил скрипт, который инкапсулирует в себе логику открытия файла и xml-сериализацию:

#r "nuget: System.Text.Encoding.CodePages"#r "AKIM.Protocol.dll"open System.IOopen AKIM.Protocolopen System.Xml.Serializationopen System.Textlet loadSep path=        let deserializeXml (xml : string) =        let toBytes (x : string) = Encoding.UTF8.GetBytes x        let xmlSerializer = XmlSerializer(typeof<Experiment>)        use stream = new MemoryStream(toBytes xml)        xmlSerializer.Deserialize stream :?> Experiment    Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)        deserializeXml (File.ReadAllText(path, Encoding.GetEncoding(1251)))

В этом скрипте я подключаю nuget пакет для кодировки и свою библиотеку с dto-классами, написанную на C#.

Во втором блоке notebook'a уже в c#-intaractive я подключаю нужные для работы с экспериментом пространства имён и шарю объект в с# из f#, определенного в первом блоке

#r "AKIM.Protocol.dll"using AKIM.Protocol;using AKIM.Protocol.Events;using AKIM.Protocol.Events.OperatorSvn;using AKIM.Protocol.Events.OperSb;using AKIM.Protocol.Events.RespUnits;using AKIM.Protocol.Events.Intruders;using AKIM.Protocol.Events.Sens;using AKIM.Protocol.Events.System;#!share --from fsharp Experiment

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

var allTests = Experiment.Tests.Count;var penetrations = Experiment.Tests.Where(t => t.Events.Last() is PenetrationEvent).Count();var nonPenetrations = Experiment.Tests.Where(t => t.Events.Last() is NonPenetEvent).Count();var eve = Experiment.Tests.First().Events.FirstOrDefault(t => t is VisContactEvent);Console.WriteLine(eve?.GetDescription());Console.WriteLine($"Количество проникновений {penetrations} из {allTests}")

Нажав на запуск выполнения кода мы получаем следующий вывод:

А дальше я могу использовать полученные значения для построения красивой диаграммы или графика, например:

#r "nuget: XPlot.Plotly"#!share --from csharp penetrations #!share --from csharp nonPenetrations#!share --from csharp allTestsopen XPlot.PlotlyChart.Pie(seq {("Кол-во проникновений",penetrations);               ("Нейтролизовали",allTests- penetrations-nonPenetrations);               ("Отказ от проникновения",nonPenetrations)}) |> Chart.Show

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

Что дальше

В дальнейшем, есть идея описать язык взаимодействия с событиями на F# в виде отдельной библиотеки или скрипта, как это было описано, например, тут. Так как, на мой взгляд, подобный notebook должен заполнять аналитик проекта, а не программист.

Что не работает?

Мне не удалось загрузить файл скрипта на С# с расширениями "*.csx" в с#-interactive. Возможно еще не завезли, возможно не правильно готовлю. Плюс не удалось решить, почему графики открываются в браузере, а не снизу блока с кодом. Также в markdown блоке не хотят отображаться формулы в формате $$...$$.

Выводы

Я считаю, что этот инструмент должен попробовать каждый .net разработчик. Вариантов использования масса: обработка результатов, прототипирование каких-то идей, изучение F# или C#, скриптинг для работы с операционной системой, например, чтобы manage'ить какие-то файлы. Лично я, когда случайно узнал вчера об этом инструменте, был в диком восторге, что и побудило меня сделать этот пост, так как мало, кто об этой штуке слышал (но это не точно).

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

Жду отзывов об использовании этой штуки в комментариях + возможно, кто-то даст подсказки на решение проблем, которые у меня возникли с графиками и загрузкой c# скриптов.

Спасибо за внимание.

Полезные ссылки

Официальная репа, в которой есть также документация
.NET Interactive + ML.NET
Новые фичи f#(в начале видео использует dotnet-intaractive)

В рамках глобальной технологической конференции Miсrosoft Build 2021, которая проходит с 25 по 27 мая в онлайн-формате, компания продемонстрировала новые решения для разработчиков, а также совместно с партнерами анонсировала инициативу в области устойчивого развития.

Это 8 анонсов конференции Microsoft Build, которые подобрала наша бизнес-команда. Ну а подборку от команды разработки ждите завтра!

Главные новости:

• Анонспервого продуктаMicrosoftна базе GPT-3.Одна из самых мощных моделей естественного языка в мире GPT-3 от OpenAI будет интегрирована в платформу для low-code разработки Microsoft Power Apps. Благодаря искусственному интеллекту пользователи теперь смогут создавать приложения без глубоких знаний кода или формул, используя диалоговые команды. GPT-3 работает в облаке Microsoft Azure, а для ее дообучения был использован сервис Azure Machine Learning. Интеграция станет одним из первых применений модели в решении прикладных бизнес-задач.

• ЗапускФонда экологичного ПОGreenSoftwareFoundation.Учредители фонда Microsoft, GitHub, Accenture и ThoughtWorks при поддержке Linux Foundation намерены приложить усилия к популяризации экологичного подхода к разработке ПО, для того чтобы компании ИТ-сектора могли внести свой вклад в снижение уровня углеродных выбросов. Также они будут инициировать создание отраслевых стандартов и стимулировать инновационные разработки в данной области в сотрудничестве с некоммерческими и научными организациями.

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

• ИнтеграцияAzure Security CenterиGitHub.Функция позволит отслеживать результаты сканирования контейнеров, полученные с помощью GitHub Actions. Благодаря этому команды SecOps (Security Operations) смогут быстрее реагировать и оповещать о проблемах, что обеспечит более продуктивную коллаборацию между ними и разработчиками.

• Возможностьзапускать сервисыAzureна базеKubernetesв любом месте с помощьюAzureArc.Теперь у разработчиков появилась возможность запускать различные службы приложений Azure (Azure App Service, Azure Functions, Azure Logic Apps, Azure API Management, Azure Event Grid) где угодно включая облака от разных производителей, таких как Amazon и Google, локальные серверы и устройства граничных вычислений.

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

• РасширениеVisual StudioдляPower Platform.Оно позволит разработчикам использовать знакомые инструменты Visual Code в платформе Power Platform. Это откроет новые возможности для совместной работы разработчиков и сотрудников из бизнес-подразделений.

• Поддержкаприложений графического интерфейса пользователя (GUI) Linux в подсистеме Windows для Linux (WSL).WSL позволяет пользователям запускать свои любимые инструменты, утилиты и приложения Linux. Теперь она также включает поддержку приложений GUI. Они работают из коробки, что позволяет тестировать, разрабатывать и запускать полноценные приложения Linux GUI на устройстве под управлением Windows без настройки традиционной виртуальной машины.

Введение

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

В целом, локализация консоли Windows при наличии соответствующего языкового пакета не представляется сложной. Тем не менее, полное и однозначное решение этой проблемы, в сущности, до сих пор не найдено. Причина этого, главным образом, кроется в самой природе консоли, которая, являясь компонентом системы, реализованным статическим классом System.Console, предоставляет свои методы приложению через системные программы-оболочки, такие как командная строка или командный процессор (cmd.exe), PowerShell, Terminal и другие.
По сути, консоль находится под двойным управлением - приложения и оболочки, что является потенциально конфликтной ситуацией, в первую очередь в части использования кодировок.

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

Виды консолей

В общем случае функции консоли таковы:

• управление операционной системой и системным окружением приложений на основе применения стандартных системных устройств ввода-вывода (экран и клавиатура), использования команд операционной системы и/или собственно консоли;

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

Основная консоль Windows - командная строка или иначе командный процессор (CMD). Большие возможности предоставляют оболочки PowerShell (PS), Windows PowerShell (WPS) и Terminal. Отдельным видом консоли можно считать консоль отладки Visual Studio (CMD-D).

Конфликт кодировок

Полностью локализованная консоль в идеале должна поддерживать все мыслимые и немыслимые кодировки приложений, включая свои собственные команды и команды Windows, меняя "на лету" кодовые страницы потоков ввода и вывода. Задача нетривиальная, а иногда и невозможная - кодовые страницы DOS (CP437, CP866) плохо совмещаются с кодовыми страницами Windows и Unicode.

История кодировок здесь: О кодировках и кодовых страницах / Хабр (habr.com)

Исторически кодовой страницей Windows является CP1251 (Windows-1251, ANSI, Windows-Cyr), уверенно вытесняемая 8-битной кодировкой Юникода CP65001 (UTF-8, Unicode Transformation Format), в которой выполняется большинство современных приложений, особенно кроссплатформенных. Между тем, в целях совместимости с устаревшими файловыми системами, именно в консоли Windows сохраняет базовые кодировки DOS - CP437 (DOSLatinUS, OEM) и русифицированную CP866 (AltDOS, OEM).

Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8. Мир любит Юникод, а кроссплатформенность без него вообще невозможна.

Совет 2. Периодически проверять кодировку, например в текстовом редакторе Notepad++. Visual Studio может сбивать кодировку, особенно при редактировании за пределами VS.

Поскольку в консоли постоянно происходит передача управления от приложений к собственно командному процессору и обратно, регулярно возникает "конфликт кодировок", наглядно иллюстрируемый таблица 1 и 2, сформированных следующим образом:

Были запущены три консоли - CMD, PS и WPS. В каждой консоли менялась кодовая страница с помощью команды CHCP, выполнялась команда Echo c двуязычной строкой в качестве параметра (табл. 1), а затем в консоли запускалось тестовое приложение, исходные файлы которого были созданы в кодировке UTF-8 (CP65001): первая строка формируется и направляется в поток главным модулем, вторая вызывается им же, формируется в подключаемой библиотеке классов и направляется в поток опять главным модулем, третья строка полностью формируется и направляется в поток подключаемой библиотекой.

using System;using ova.common.logging.LogConsole;using Microsoft.Extensions.Logging;using ova.common.logging.LogConsole.Colors;namespace LoggingConsole.Test{    partial class Program    {        static void Main2(string[] args)        {            ColorLevels.ColorsDictionaryCreate();            Console.WriteLine("Hello World! Привет, мир!");     //вывод строки приветствия на двух языках            LogConsole.Write("Лог из стартового проекта", LogLevel.Information);            Console.WriteLine($"8. Active codepage: input {Console.InputEncoding.CodePage}, output {Console.OutputEncoding.CodePage}");            Console.ReadKey();        }     }}

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

Вывод тестового приложения локализован лишь в 50% испытаний, как показано в табл.2.

Сoвет 3. Про PowerShell забываем раз и навсегда.

По умолчанию Windows устанавливает для консоли кодовые страницы DOS. Чаще всего CP437, иногда CP866. Актуальные версии командной строки cmd.exe способны локализовать приложения на основе русифицированной кодовой страницы 866, но не 437, отсюда и изначальный конфликт кодировок консоли и приложения. Поэтому

Совет 4. Перед запуском приложения необходимо проверить кодовую страницу консоли командой CHCP и ей же изменить кодировку на совместимую - 866, 1251, 65001.

Совет 5. Можно установить кодовую страницу консоли по умолчанию. Кратко: в разделе реестра \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor добавить или изменить значение параметра Autorun на: chcp <номер кодовой страницы>. Очень подробно здесь: Изменить кодовую страницу консоли Windows по умолчанию на UTF-8 (qastack.ru)

Проблемы консолей Visual Studio

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

Отдельной опцией Visual Studio является встроенная односеансная консоль отладки, которая перехватывает команду Visual Studio на запуск приложения, запускается сама, ожидает компиляцию приложения, запускает его и отдает ему управление. Таким образом, отладочная консоль в течение всего рабочего сеанса находится под управлением приложения и возможность использования команд Windows или самой консоли, включая команду CHCP, не предусмотрена. Более того, отладочная консоль не воспринимает кодовую страницу по умолчанию, определенную в реестре, и всегда запускается в кодировке 437 или 866.

Совет 6. Тестирование приложения целесообразно выполнять во внешних консолях, более дружелюбных к локализации.

Анализ проблем консолей был бы не полон без ответа на вопрос - можно ли запустить консольное приложение без консоли? Можно - любой файл ".exe" запустится двойным кликом, и даже откроется окно приложения. Однако консольное приложение, по крайней мере однопоточное, по двойному клику запустится, но консольный режим не поддержит - все консольные вводы-выводы будут проигнорированы, и приложение завершится

Локализация отладочной консоли Visual Studio

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

На самом деле, правильнее говорить о локализации приложения в консоли - это важное уточнение. Microsoft по этому поводу высказывается недвусмысленно: "Programs that you start after you assign a new code page use the new code page.However, programs (except Cmd.exe) that you started before assigning the new code page will continue to use the original code page". Иными словами, консоль можно локализовать когда угодно и как угодно, но приложение будет локализовано в момент стабилизации взаимодействия с консолью в соответствии с текущей локализацией консоли, и эта локализация сохранится до завершения работы приложения. В связи с этим возникает вопрос - в какой момент окончательно устанавливается связь консоли и приложения?

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

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

F:\LoggingConsole.Test\bin\Release\net5.0>chcpActive code page: 1251F:\LoggingConsole.Test\bin\Release\net5.0>loggingconsole.testCodepages: current 1251:1251, setted 437:437,  5  -: =Codepages: current 437:437, setted 65001:65001,  5  -: =Codepages: current 65001:65001, setted 1252:1252,  5  -: =Codepages: current 1252:1252, setted 1251:1251, вводим 5 символов по-русски: йцуке=йцукеCodepages: current 1251:1251, setted 866:866, ттюфшь 5 ёшьтюыют яю-Ёёёъш: щъх=щъхCodepages: current 866:866, setted 1251:1251, вводим 5 символов по-русски: йцуке=йцукеCodepages: current 1251:1251, setted 1252:1252,  5  -: =F:\LoggingConsole.Test\bin\Release\net5.0>chcpActive code page: 1252

• приложение запущено в консоли с кодовыми страницами 1251 (строка 2);

• приложение меняет кодовые страницы консоли (current, setted);

• приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);

• по окончании работы приложения изменения консоли сохраняются (строка 14 - Active codepage 1252);

• Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).

using System;using System.Runtime.InteropServices;namespace LoggingConsole.Test{    partial class Program    {        [DllImport("kernel32.dll")] static extern uint GetConsoleCP();        [DllImport("kernel32.dll")] static extern bool SetConsoleCP(uint pagenum);        [DllImport("kernel32.dll")] static extern uint GetConsoleOutputCP();        [DllImport("kernel32.dll")] static extern bool SetConsoleOutputCP(uint pagenum);                static void Main(string[] args)        {            Write(437);            Write(65001);            Write(1252);            Write(1251);            Write(866);            Write(1251);            Write(1252);         }        static internal void Write(uint WantedIn, uint WantedOut)        {            uint CurrentIn = GetConsoleCP();            uint CurrentOut = GetConsoleOutputCP();            Console.Write($"current {CurrentIn}:{CurrentOut} - текущая кодировка, "); /*wanted {WantedIn}:{WantedOut},*/            SetConsoleCP(WantedIn);            SetConsoleOutputCP(WantedOut);            Console.Write($"setted {GetConsoleCP()}:{GetConsoleOutputCP()} - новая кодировка, ");            Console.Write($"вводим 3 символа по-русски: ");            string str = "" + Console.ReadKey().KeyChar.ToString();            str += Console.ReadKey().KeyChar.ToString();            str += Console.ReadKey().KeyChar.ToString();            Console.WriteLine($"={str}");        }              static internal void Write(uint ChangeTo)        {            Write(ChangeTo, ChangeTo);        }    }}

Программное управление кодировками консоли - это единственный способ гарантированной адекватной локализацией приложения в консоли. Языки .Net такой возможности не предоставляют, однако предоставляют функции WinAPI: SetConsoleCP(uint numcp) и SetConsoleOutputCP(uint numcp), где numcp - номер кодовой страницы потоков ввода и вывода соответственно. Подробнее здесь: Console Functions - Windows Console | Microsoft Docs. Пример применения консольных функций WInAPI можно посмотреть в тестовом приложении под катом выше.

Совет 7. Обязательный и повторный! Функции SetConsoleCP должны размещаться в коде до первого оператора ввода-вывода в консоль.

Стратегия локализации приложения в консоли

1. Удалить приложение PowerShell, заменив его Windows PowerShell;

2. Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5;

3. Разработку приложений выполнять в кодировке utf-8 Unicode;

4. Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad++;

5. Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:

using System;using System.Runtime.InteropServices;namespace LoggingConsole.Test{    partial class Program    {      static void Main(string[] args)        {          [DllImport("kernel32.dll")] static extern bool SetConsoleCP(uint pagenum);        [DllImport("kernel32.dll")] static extern bool SetConsoleOutputCP(uint pagenum);            SetConsoleCP(65001);        //установка кодовой страницы utf-8 (Unicode) для вводного потока            SetConsoleOutputCP(65001);  //установка кодовой страницы utf-8 (Unicode) для выводного потока             Console.WriteLine($"Hello, World!");        }    }}