Комментарии 26
>Поэтому, когда речь зашла о переходе всей компании на MacBook в будущем, мы решили выяснить, как это отразится на производительности.
Но даже после фикса нет прироста производительности от макбука. В чём смысл перехода тогда?
Но даже после фикса нет прироста производительности от макбука. В чём смысл перехода тогда?
Даже сейчас большинство разработчиков выбирают в качестве рабочей машины макбук, и исправление этой проблемы улучшило developer experience в том числе и для текущих сотрудников. Также для перехода оценивался полный набор задач разработчика, и сборка является лишь его частью.
А зачем вообще нужны эти вотчеры в режиме сборки с отключенными билд-сераерами?
И вообще, если речь идёт о подключаемыми к компилятору плагине - почему за изменениями файлов следит не компилятор, а сам плагин?
А зачем вообще нужны эти вотчеры в режиме сборки с отключенными билд-сераерами?
Сборка с отключенными билд-серверами проводилась только для чистоты эксперимента, по умолчанию сборка происходит с включенными (вне зависимости, у разработчика на машине или в CI).
И вообще, если речь идёт о подключаемыми к компилятору плагине - почему за изменениями файлов следит не компилятор, а сам плагин?
Так как файлы локализации не являются частью исходного кода, изменения в них не отслеживаются компилятором, и анализатору приходится следить за ними самому. В случае исходного кода компилятор сам оповещает анализатор об изменениях (подписаться на которые можно, используя методы CompilationStartAnalysisContext.Register*Action)
Разве нельзя сделать две версии анализатора - один для билда, другой для live analysis (реюзая базовый код при этом)?
Тогда watch для билда совсем можно не делать (если только у вас не совсем что-то извращённое с ресурсами).
К сожалению нет, архитектура Roslyn не разделяет их на разные типы — для анализатора нет никакой разницы, запущен он в IDE или при сборке
К сожалению нет, архитектура Roslyn не разделяет их на разные типы — для анализатора нет никакой разницы, запущен он в IDE или при сборке
Может я не максимально понятно выразился. Для анализатора может и нет, но что мешает написать два анализатора и один настроить для билда, а другой для IDE? В документации есть, сам не пробовал, потому что не требовалось.
P.S. На случай, если новый редактор что-то сотворит со ссылкой, вот названия настроек оттуда:
<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
<RunAnalyzersDuringLiveAnalysis>false</RunAnalyzersDuringLiveAnalysis>
<RunAnalyzers>false</RunAnalyzers>Посмотрела документацию, вроде бы этих свойств больше нет на .NET (Core) и вместо этого полагается на настройки Visual Studio (которой на маках нет), поэтому это может и не работает. Распиливать один анализатор на два причины не было, так как проще исправить именно использование FileSystemWatcher.
А куда они делись? Или вы думаете, что "галочки", поставленные в студии, записываются куда-то в другое место?
Быстро пробежавшись по репозиториям, я не вижу кода, где в зависимости от этих параметров менялось бы поведение; реализация вполне может быть на стороне IDE.
Плохо искали, вот тут все эти параметры используются: https://github.com/dotnet/roslyn/
Другое дело, что эти флаги - вообще не то что вам нужно, потому что они отключают анализ кода целиком, а не выбранные анализаторы.
Формат файла проекта MSBuild со времен .NET Framework поменялся. Новый (SDK-based) для .NET(Core) работает (формально) по тем же правилам, но вот информацию (Properties, Items и пр.) по факту берет из других мест, зачастую переписывая то, что указано в файле проекта. На SO предлагают эти настройки закидывать в Directory.Build.targets и указывать Target через параметры команды msbuild. Якобы, (не проверял) работает и без Visual Studio.
Вы всё напутали, это не формат файла проекта поменялся, это компилятор поменялся, а у нового компилятора - новые настройки. Формат там, конечно, поменялся тоже - но не до того уровня что сам ваши настройки перезаписывает.
Вопрос на SO, на который вы ссылаетесь - из эпохи, когда компилятор уже поменяли, а настройки добавить не успели. Сейчас ни тот вопрос, ни тот ответ не актуальны.
Вы всё напутали, это не формат файла проекта поменялся,
Нет, поменялся именно формат файла проекта, и именно для системы сборки, каковой является MSBuild. MS называет такие проекты SDK-style project. Точнее, формально формат тот же (XML), но добавлены и, главное, используются новые элементы и атрибуты. В результате базовые настройки сборки импортируются из совсем других мест и предусматривают другие точки расширения для донастройки. Потому на практике старые способы расширения (которые собственно и использовались в реальных проектах) часто не работают.
Если вы переносили проект с .NET Framework в .NET(Core), то должны были с этим столкнуться: файл проекта толком не переносится. Когда я это делал, года два назад, у MS вообще была рекомендация создать новый проект и перенести исходные файлы и настройки туда. Были, правда, сторонние средства для конвертации, но они работали через пень колоду (я пробовал). Короче, работа была творческая, благо проект был совсем небольшим.
Ну и работают ли рекомендации из указанной статьи SO (сейчас или вообще) я не проверял.
Конкретно к запуску анализаторов смена формата проекта не имеет никакого отношения.
Если вы переносили проект с .NET Framework в .NET(Core), то должны были с этим столкнуться: файл проекта толком не переносится. Когда я это делал, года два назад, у MS вообще была рекомендация создать новый проект и перенести исходные файлы и настройки туда.
Забавно, но это был самый лёгкий перенос проекта, даже несмотря на то, что и правда пришлось пересоздать проект заново. Переходить с Build tools 2012 на Build tools 2013 было куда сложнее...
Ну и работают ли рекомендации из указанной статьи SO (сейчас или вообще) я не проверял.
Я тоже не проверял, но не вижу причин не работать. Другое дело - зачем? С тех пор появилась настройка RunAnalyzers.
Что-то вспомнилось - лет 30 назад как раз для Маков еще тогдашних классических выходили статьи, где два эксперта, как и тут начиная с очевидной проблемы очень похоже локализовали ее по шагам до источника с обязательным "- Nasty. -Yeah." в конце :)
Получается, у разработчиков локально одна архитектура, а на серваках совсем другая, если конечно там тоже не ARM. Мне кажется такое решение контрпродуктивно по своей сути.
Такой вопрос, а зачем вы используете самописную систему с file watcher вместо штатных рослиновских средств отслеживания изменений в AdditionalFiles?
Еще можно посоветовать:
Шаг 0 - обновить sdk хотя бы в рамках мажорки, может быть проблема уйдет
Шаг 0.1 - снести с машины все SDK кроме нужного
Натыкались на странные проблемы которые решались именно так
Медленная сборка кода с .NET Roslyn: как найти и устранить причину