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

На самом деле, нет. Visual Studio - “большой зверь”, которым ежедневно пользуются миллионы профессиональных разработчиков. Версия за версией Microsoft тратит невероятные усилия, чтобы улучшить ее и обеспечить соответствие последним стандартам с точки зрения платформ разработки, функций IDE, удобства использования и производительности.

Это подразумевает множество глубоких изменений, и все расширения VS должны адаптироваться к этим изменениям ... или умереть. Большая часть этих усилий по адаптации исходит от поддержки новых платформ (.NET Core, Xamarin, готовится к выпуску .NET 5 ...), но сейчас мы бы хотели сосредоточиться на последних изменениях интеграции VS.

Загрузка отложенных расширений

11 декабря 2017 года все партнеры VS получили письмо с объявлением об отложенной загрузке пакета VS, в котором также упоминалось расширение асинхронной инициализации. В этом режиме расширения VS загружаются после запуска и инициализации VS. Как следствие, запуск VS не замедляется расширениями.

Реализация этого сценария потребовала серьезных изменений, но этот сценарий отложенной загрузки стал обязательным только с VS 2019.1 (16.1), выпущенным этой весной 2019 года, примерно через 18 месяцев после первоначального объявления. ISV с расширением VS получил достаточно времени (и много качественной поддержки от инженеров Microsoft) для реализации и тестирования этой схемы асинхронной загрузки.

Меню расширений VS2019

В феврале 2019 года, когда разрабатывалась поддержка NDepend для VS 2019, загружалась последняя версия предварительного просмотра VS2019, и устанавливалось расширение NDepend, разработчики заметили, что глобального меню NDepend больше нет. После исследования они увидели главное меню NDepend и другие меню расширений в новом меню «Extensions» - без возможности вернуться в меню расширений на главной панели.

Visual Studio 2019 Extensions Menu

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

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

Visual Studio 2019 Compact Menu

Где-то в апреле 2019 года кто-то анонимно опубликовал в обсуждении ссылку на новое расширение, чтобы вернуть основные меню расширений в главную панель.

Возвращение расширений в главное меню

Есть предположения, что API-интерфейсы VS, используемые для достижения этой магии, недостаточно хорошо документированы, поэтому мы можем задаться вопросом, исходит ли эта инициатива от MS или нет? По крайней мере, теперь пользователи могут вернуться к своим меню расширений в главной панели. Но расширение «Extensions in Main Menus» было загружено только 800 раз за 3 месяца. Это означает, что только крошечное подмножество пользователей расширений VS знают об этом и фактически используют его.

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

VS2019 Оптимизация рендеринга для экранов с разной плотностью пикселей

NDepend v2019.2.0 была опубликована 14 марта 2019 года с гордой поддержкой VS2019 и .NET Core 3. Через две недели пользователь сообщил о серьезных ошибках пользовательского интерфейса, которых разработчики NDepend никогда не наблюдали. Схема репро была простой:

• установить .NET Fx 4.8,
• включить новую опцию VS2019 - Optimize rendering for screens with different pixel densities (Оптимизировать рендеринг для экранов с разной плотностью пикселей)
• запустить VS2019 с расширением NDepend в среде с несколькими мониторами с различным масштабом DPI для каждого монитора

Optimize rendering for screens with different pixel densities 

Затем разработчики NDepend обсудили эту проблему с инженерами VS. Они указали нам на эту документацию и любезно предложили несколько специальных советов: поддержка Per-Monitor Awareness для расширений Visual Studio

На самом деле это изменение довольно серьезно для (тонны) элементов управления WPF и Winforms, визуализированных в интерфейсе Visual studio. Это заняло у разработчиков время, но они только что выпустили (3 июля 2019 года) NDepend v2019.2.5 с полной поддержкой этого параметра “Optimize rendering for screens with different pixel densities”. Это потребовало довольно сложных исправлений. 

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

Сообщение  Resharper, связанное с оптимизацией рендеринга для экранов с различной плотностью пикселей

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

Что мы можем ожидать дальше?

С публичным объявлением .NET 5 6 мая 2019 года сообщество .NET теперь знает, что рано или поздно большинство приложений .NET Core или .NET Fx придется перенести, чтобы воспользоваться последними инновациями и улучшениями.

Надеемся, что миграция приложений .NET Core будет довольно простой, поскольку .NET 5 - это .NET Core vNext. Но миграция приложений .NET Fx будет (более или менее) болезненной. Хотя API-интерфейсы WPF и Winforms для настольных компьютеров уже поддерживаются .NET Core 3, некоторые другие основные API-интерфейсы не поддерживаются и не будут поддерживаться (веб-формы ASP.NET, WCF, рабочий процесс Windows, .NET Remoting, AppDomain…).

Для слишком сложных планов миграции вот рекомендация Microsoft: “Что вы делаете со своими старыми приложениями, на которые вы не тратите много времени на разработку? Мы рекомендуем оставить их на .NET Framework. (…) .NET Framework будет по-прежнему поддерживаться и будет получать незначительные обновления. Даже здесь, в Microsoft, многие крупные продукты останутся в .NET Framework. Нет абсолютно никаких изменений в поддержке, и это не изменится в будущем. .NET Framework 4.8 является последней версией .NET Framework и будет распространяться с будущими выпусками Windows. Если он установлен в поддерживаемой версии Windows, платформа .NET Framework 4.8 также будет поддерживаться”.

Visual Studio 2019 по-прежнему работает в 32-разрядном процессе на .NET Fx 4 CLR с массивным пользовательским интерфейсом на основе WPF и некоторым использованием COM.

Можем ли мы ожидать, что VS2019 будет работать на .NET 5 в 2021 году? или в более поздней версии? или никогда?

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

No Comments