Большинство из вышеперечисленного я лично (при личных встречах) озвучивал разработчикам и менеджерам из соответствующих команд. И мы соглашались с тем, что это важные баги. Не знаю, что я могу еще сделать? То есть что я могу сделать я знаю и делаю, мы находим пути как обойти отсутствующие точки расширения, заткнуть мешающую функциональность и перекрыть фичи, которые не предназначены для того чтобы их перекрывать. Приведу пример: для того чтобы FTS понимал что мы программно перемещаем файл, мы в нашем коде эмулируем drag-and-grop в solution explorer. чтобы делать рефакторинги и темплэйты в xaml файлах мы при опять же программном изменении тэгов боремся с фичей студии по синхронному редактированию тэгов. Сколько людей поддержат реквест про то что какой-то API не выдает события в каких-то случаях? У нас такие проблемы возникают каждую неделю. И для нас это business critical. И пользователи ждут что все заработает сразу после выхода очередной версии студии. Добиться разъяснений сложно, добиться изменений невозможно.
1. Совершенно согласен, просят. Активно.
2. При планировании новых продуктов действительно учитывают и принимают баги в развивающихся продуктах.
3. Проблема в том, что есть продукты уже развившиеся и есть направления, которые находятся вне фокуса, в режиме поддержки. Приведу пример проблем в VS 2010-2015 которые не являются приоритетными и не исправляются:
— перезагрузка проектов после изменения проектных файлов. так квадратичная зависимость от количества проектов. в более или менее больших солюшенах единственный способ обновится из vcs — перезапуск студии.
— DirectoryWatcher. при билде он не дает ничего делать, так как заничет UI поток обработкой изменения на диске. Там проблема стандартная в том, что переполняется кэш File system watcher-а и происходит обход большого поддерева файловой системы полностью. (сейчас — в 2015 upsate 1, добавились memory leaks: twitter.com/serjic/status/670190879089520641)
— запуск MsBuild при редактировании проекта (добавление файлов или ссылок) может вызвать паузы в искусственно вызванном GC в десятки секунд.
— уже упомянутое здесь редактирование xaml файлов.
— сейчас добавились многочисленные проблемы с производительностью roslyn.
— и еще безумно много мелких проблем…
Я соглашусь, что баги есть у всех. Да, VS — качественный продукт. Там мало фич, но то что есть сделано качественно. Это качество дается не бесплатно, мой опыт показывает что добиться исправлений или улучшений в некоторых областях невозможно.
этой настройкой мы даже пользовались до 10.0 для отключения студийной подсветки. К сожалению Language service обслуживает еще очень много фич в VS начиная с IntelliSense и заканчивая диаграммами, дебаггером итд. То есть, отключая отдельные фичи, мы не остановим Roslyn, не заставим его потреблять меньше памяти. Ну или что-то отломаем для пользователей. Из действенного есть галочка в опциях (что-то типа analyze files opened in editor) — она заставляет студию не анализировать файлы которые не открыты в редакторе с целью показать там ошибки в errors view.
Спасибо, все очень актуально.
1. Баг есть, при сохранении xaml файлов студийный Language Service для xaml вызывает перекомпиляцию. Это действительно нужно для работы VS IntelliSense, так как из xaml можно использовать C# код и наоборот, компиляция происходит сложно, в два прохода. Но сами тормоза обусловлены тем, что при недостатке памяти MsBuild, который работает in-process в devenv.exe, пытается освободить память путем сериализации на диск 10% из своих внутренних структур данный. И проверяет результат, вызывая GC 2. По тем же причинам может втыкать добавление и удаление файлов или ссылок в проектах.
Из рекомендаций — переключить дефолтный редактор на source code editor (вместо xaml editor), перенести общие контролы (использующиеся в xaml в другой проект чтобы избежать 2-стадийной компиляции). Уменьшать количество проектов (если это возможно) для экономии памяти. Отключать фичи решарпера которыми Вы не пользуетесь в окошке опций.
2. В 10.0.2 нет DevExpress уже. Пожалуйста, присылайте профили если что-то все еще тормозит.
Пока эта фича пока не запланирована на следующую версию. Более долгосрочный планов мы не делаем. Внутри команды мы много раз обсуждали что нужно сделать для того чтобы анализировать async было проще, но в конкретные фичи ничего пока не превратилось. Пользуясь случаем, могу я попросить вас описать задачи которые хотелось бы решать? (какой-нибудь типичный баг в асинхронном коде которые не видно просто в dotTrace timeline) Если какая-то проддержка будет, то скорее всего только в режиме профиляции Timeline.
2. При планировании новых продуктов действительно учитывают и принимают баги в развивающихся продуктах.
3. Проблема в том, что есть продукты уже развившиеся и есть направления, которые находятся вне фокуса, в режиме поддержки. Приведу пример проблем в VS 2010-2015 которые не являются приоритетными и не исправляются:
— перезагрузка проектов после изменения проектных файлов. так квадратичная зависимость от количества проектов. в более или менее больших солюшенах единственный способ обновится из vcs — перезапуск студии.
— DirectoryWatcher. при билде он не дает ничего делать, так как заничет UI поток обработкой изменения на диске. Там проблема стандартная в том, что переполняется кэш File system watcher-а и происходит обход большого поддерева файловой системы полностью. (сейчас — в 2015 upsate 1, добавились memory leaks: twitter.com/serjic/status/670190879089520641)
— запуск MsBuild при редактировании проекта (добавление файлов или ссылок) может вызвать паузы в искусственно вызванном GC в десятки секунд.
— уже упомянутое здесь редактирование xaml файлов.
— сейчас добавились многочисленные проблемы с производительностью roslyn.
— и еще безумно много мелких проблем…
Я соглашусь, что баги есть у всех. Да, VS — качественный продукт. Там мало фич, но то что есть сделано качественно. Это качество дается не бесплатно, мой опыт показывает что добиться исправлений или улучшений в некоторых областях невозможно.
1. Баг есть, при сохранении xaml файлов студийный Language Service для xaml вызывает перекомпиляцию. Это действительно нужно для работы VS IntelliSense, так как из xaml можно использовать C# код и наоборот, компиляция происходит сложно, в два прохода. Но сами тормоза обусловлены тем, что при недостатке памяти MsBuild, который работает in-process в devenv.exe, пытается освободить память путем сериализации на диск 10% из своих внутренних структур данный. И проверяет результат, вызывая GC 2. По тем же причинам может втыкать добавление и удаление файлов или ссылок в проектах.
Из рекомендаций — переключить дефолтный редактор на source code editor (вместо xaml editor), перенести общие контролы (использующиеся в xaml в другой проект чтобы избежать 2-стадийной компиляции). Уменьшать количество проектов (если это возможно) для экономии памяти. Отключать фичи решарпера которыми Вы не пользуетесь в окошке опций.
2. В 10.0.2 нет DevExpress уже. Пожалуйста, присылайте профили если что-то все еще тормозит.