Visual Studio *

Cascadia Code наконец-то здесь! Вы можете установить его непосредственно со страницы выпусков в нашем репозитории на GitHub или автоматически получить его в следующем обновлении Windows Terminal.

Постойте, что за «Cascadia Code»?

Cascadia Code был представлен в мае этого года на мероприятии Microsoft Build. Это новейший моноширинный шрифт, поставляемый Microsoft, который обеспечивает свежий опыт работы с командной строкой и редакторами кода. Cascadia Code был разработан рука об руку с новым приложением Windows Terminal. Этот шрифт рекомендуется использовать с терминальными приложениями и текстовыми редакторами, такими как Visual Studio и Visual Studio Code.

Развивая тему недавно анонсированного Developer PowerShell, мы рады представить вам первую preview-версию нового терминала Visual Studio. Данная функция является частью Visual Studio версии 16.3 Preview 3.



Терминал Visual Studio не создан с нуля, а разделяет большую часть своего ядра с Windows Terminal. Для вас это означает более надежную работу терминала и более быстрое введение новых функций.

Поддержка Юникода в Windows появилась раньше, чем в большинстве остальных операционных систем. Из-за этого многие проблемы, связанные с представлением символов, в Windows решались не так, как в других системах, разработчики которых отложили внедрение нового стандарта до лучших времён [1]. Самый показательный пример: в Windows для представления символов Юникода используется кодировка UCS-2. Она была рекомендована Консорциумом Юникода, поскольку версия 1.0 поддерживала только 65 536 символов [2]. Пять лет спустя Консорциум передумал, но к тому времени менять что-то в Windows было уже поздно, так как на рынок уже были выпущены системы Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 и Windows 95 — все они использовали кодировку UCS-2 [3].

Но сегодня мы поговорим о строках форматирования функции printf.

Эта статья о том, как однажды мы решили немного улучшить внутренний инструмент SelfTester, применяемый для проверки качества работы анализатора PVS-Studio. Улучшение было несложным и выглядело полезным, но создало нам много проблем, и впоследствии выяснилось, что лучше бы мы его не делали.

Мы любим искать ошибки в проектах Microsoft. Почему? Всё просто: их проекты, как правило, легко проверить (работу можно вести сразу в среде Visual Studio, для которой у PVS-Studio есть удобный плагин) и они содержат мало ошибок. Поэтому обычный алгоритм работы такой: найти и скачать открытый проект от MS; проверить его; выбрать интересные ошибки; убедиться, что их немного; написать статью, не забыв похвалить разработчиков. Великолепно! Win-win-win: времени ушло немного, руководство радо появлению новых материалов в блоге, да и карма в полном порядке. Но в этот раз что-то пошло не так. Давайте посмотрим, что интересного удалось найти в исходном коде Windows Forms и стоит ли хвалить Microsoft в этот раз.

Привет! Эта статья продолжение моей статьи FFmpeg начало работы Visual Studio. Здесь мы приступим к аппаратному декодированию RTSP-потока FULL HD. Заранее скажу, что с данной задачей легко справится даже Intel ATOM Z8350.

Задача: аппаратное декодирование и запись до 4-х кадров в оперативную память для последующей параллельной обработки (четырьмя ядрами процессора) с IP-камеры RTSP h.264. Обработанные кадры отображаю с помощью функций WinAPI. Как итог мы получим быстродействующую систему для компьютерной обработки RTSP-потока в параллельном режиме. Далее можно подключать алгоритмы Компьютерного зрения для обработки кадров Real Time.

Вступление

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

DirectX Video Acceleration (DXVA) — это API для использования аппаратного ускорения для ускорения обработки видео силами графических процессоров (GPU). DXVA 2.0 позволяет перенаправлять на GPU большее количество операций, включая захват видео и операции обработки видео.

Представим типичную ситуацию на первом курсе: вы прочитали про алгоритм Диница, реализовали, а он не заработал, и вы не знаете, почему. Стандартное решение — это начать отлаживать по шагам, каждый раз рисуя текущее состояние графа на листочке, но это жутко неудобно. Я попробовала исправить положение в рамках семестрового проекта по Software Engineering, а в посте расскажу, как у меня в итоге получился плагин для Visual Studio. Скачать можно тут, исходный код и документацию можно посмотреть тут. Вот скриншот графа, который получился для алгоритма Диница.

Всем привет

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

Привет, Хабр!

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

ВНИМАНИЕ! Информация, описанная ниже, написана исключительно в исследовательских целях и не предназначена для использования в корыстных целях!

Начну, пожалуй с предыстории.

А именно, c конца 2013 года. Тогда перед мной, как помню, возникла проблема поиска удобной IDE для быстрой и главное простой реализации прикладных задач. Надо сказать, что на тот момент я перегорел к JAVA и, хоть NetBeans мне нравилась, хотелось скорости работы и простоты разработки (Не забываем, что Java SE 6 была ну ооочень медленной). Короче, захотелось С/C++. Многие мои знакомые тогда использовали VS 2012 и, конечно, рекомендовали её мне с пеной у рта, мол лучшая IDE и бла-бла-бла. Ага, весила она на тот момент (развернутой) 15-20Gb и съедала почти всю оперативку (4Gb под Windows + VS), и ещё при всем при этом глючила безбожно. Но я готов был закрыть на это глаза, основной-то код я всегда пишу в Notepad++. Но "грязь" в IDE я пережить так и не смог (когда ради консольного приложения программа пишет 100500+ строк кода — это меня бесит и по сей день, я же не форму прошу сделать....) В итоге, удалил я VS 2012 и забыл о ней до 2017 года.

На прошлой неделе на Xamarin Developer Summit мы анонсировали «Горячую перезагрузку (Hot Reload) XAML для Xamarin.Forms», которая позволяет вносить изменения в пользовательский интерфейс XAML и просматривать их в режиме реального времени, не требуя другой сборки и развертывания.

Горячая перезагрузка XAML для Xamarin.Forms ускоряет разработку и упрощает сборку, экспериментирование и итерации в пользовательском интерфейсе. А это значит, что вам больше не нужно перестраивать свое приложение каждый раз, когда вы настраиваете свой пользовательский интерфейс — все изменения мгновенно показываются в запущенном приложении.

Когда ваше приложение скомпилировано с использованием XAML Hot Reload, оно работает со всеми библиотеками и сторонними элементами управления. Эта фича будет доступна для iOS и Android в Visual Studio 2019 и Visual Studio 2019 для Mac. Все работает на всех допустимых целях развертывания, включая симуляторы, эмуляторы и физические устройства.

Горячая перезагрузка XAML будет доступна позже в 2019 году, но вы можете зарегистрироваться для участия в preview:

Sign Up for the Preview Now

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

Чтобы упростить написание хороших расширений, мы работаем с сообществом над разработкой простого чек-листа. Существует даже GitHub issue template, который вы можете использовать. В этой статье рассмотрим 9 правил крутого расширения. Подробности под катом.

Roslyn, платформа компилятора .NET, помогает обнаруживать ошибки еще до запуска кода. Одним из примеров является анализатор проверки орфографии Roslyn, который встроен в Visual Studio. Скажем, вы создаете статический метод и случайно написали слово static как statc. Вы сможете увидеть эту орфографическую ошибку еще до запуска своего кода, потому что Roslyn выдаст предупреждение в вашем коде при вводе текста еще до завершения набора строки. Другими словами, вам не нужно производить сборку кода, чтобы узнать, что вы допустили ошибку.



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

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

1. Хотите вернуться к последней отредактированной строке кода? Попробуйте сочетание клавиш Ctrl+Shift+Bkspce, чтобы перейти к последнему месту редактирования.

2. Легко перемещайте указатель инструкций (желтая стрелка) во время отладки при помощи Set Next Statement.

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

И так, кому интересно посмотреть на то как можно сделать библиотеку наподобие AutoMapper прошу под кат.

Работа с VS Code Remote и Windows Subsystem for Linux (WSL) дает возможность использовать полнофункциональную среду разработки Linux на ноутбуке или десктопе с предустановленной Windows. В этом материале рассмотрим то, как использовать эти инструменты для разработки приложений на Python в Linux.

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

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

Многие наши статьи посвящаются чему угодно, но только не самому инструменту PVS-Studio. А ведь мы очень много делаем, чтобы разработчикам было удобно пользоваться нашим инструментом. Но как раз это часто оказывается за кадром. Решил исправить эту ситуацию и рассказать о плагине PVS-Studio для Visual Studio. Если вы используете Visual Studio, то эта статья для вас.

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

Отладчик

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



Поддерживается начиная с Visual Studio 2005

Reattach to process (Shift+Alt+P) чрезвычайно полезная функция, которая помогает снова и снова присоединяться к одному и тому же процессу.



Поддерживается начиная с Visual Studio 2017 v15.8

Синяя точка на поле указывает на переключение потоков при выполнении отладки.



Поддерживается начиная с Visual Studio 2013

Продолжение под катом!

Во время анализа кода, PVS-Studio выполняет анализ потока данных и оперирует значениями переменных. Значения берутся из констант или выводятся из условных выражений. Мы называем их виртуальными значениями. Недавно мы улучшали их для работы с multi-character-константами и это стало поводом для создания нового диагностического правила.

Введение

Multi-character-литерал является implementation-defined, поэтому различные компиляторы могут кодировать эти литералы по-разному. К примеру, GCC и Clang задают значение, основываясь на порядке символов в литерале, тогда как MSVC перемещает их в зависимости от типа символа (обычный или escape).

В любой среде разработки есть инструмент с названием «Output». Нет нужды описывать что он делает, поскольку абсолютно все разработчики его используют в своей работе ежедневно. Он прост и консервативен.

По сути не менялся десятилетиями и до этих пор выглядит как то так:


Текст, текст и еще раз текст. Много текста...

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