Быстро пробежавшись по репозиториям, я не вижу кода, где в зависимости от этих параметров менялось бы поведение; реализация вполне может быть на стороне IDE.
Посмотрела документацию, вроде бы этих свойств больше нет на .NET (Core) и вместо этого полагается на настройки Visual Studio (которой на маках нет), поэтому это может и не работает. Распиливать один анализатор на два причины не было, так как проще исправить именно использование FileSystemWatcher.
AdditionalFiles не подходит в данной ситуации, так как файлы локализации дискаверятся динамически через файл солюшна (т.е. могут быть не подключены явно в проекте)
А зачем вообще нужны эти вотчеры в режиме сборки с отключенными билд-сераерами?
Сборка с отключенными билд-серверами проводилась только для чистоты эксперимента, по умолчанию сборка происходит с включенными (вне зависимости, у разработчика на машине или в CI).
И вообще, если речь идёт о подключаемыми к компилятору плагине - почему за изменениями файлов следит не компилятор, а сам плагин?
Так как файлы локализации не являются частью исходного кода, изменения в них не отслеживаются компилятором, и анализатору приходится следить за ними самому. В случае исходного кода компилятор сам оповещает анализатор об изменениях (подписаться на которые можно, используя методы CompilationStartAnalysisContext.Register*Action)
Но даже после фикса нет прироста производительности от макбука. В чём смысл перехода тогда?
Даже сейчас большинство разработчиков выбирают в качестве рабочей машины макбук, и исправление этой проблемы улучшило developer experience в том числе и для текущих сотрудников. Также для перехода оценивался полный набор задач разработчика, и сборка является лишь его частью.
Быстро пробежавшись по репозиториям, я не вижу кода, где в зависимости от этих параметров менялось бы поведение; реализация вполне может быть на стороне IDE.
Конкретно здесь проблема оказалась именно в коде .NET, в реализации FileSystemWatcher под macOS.
Анализ производительности сборки можно провести под любой ОС, и статья рассказывает про общий подход на примере конкретной проблемы.
Посмотрела документацию, вроде бы этих свойств больше нет на .NET (Core) и вместо этого полагается на настройки Visual Studio (которой на маках нет), поэтому это может и не работает. Распиливать один анализатор на два причины не было, так как проще исправить именно использование FileSystemWatcher.
.NET гарантирует одинаковое поведение на разных архитектурах, если эта гарантия ломается — то это баг в рантайме, который стараются быстро пофиксить.
AdditionalFilesне подходит в данной ситуации, так как файлы локализации дискаверятся динамически через файл солюшна (т.е. могут быть не подключены явно в проекте)К сожалению нет, архитектура Roslyn не разделяет их на разные типы — для анализатора нет никакой разницы, запущен он в IDE или при сборке
Сборка с отключенными билд-серверами проводилась только для чистоты эксперимента, по умолчанию сборка происходит с включенными (вне зависимости, у разработчика на машине или в CI).
Так как файлы локализации не являются частью исходного кода, изменения в них не отслеживаются компилятором, и анализатору приходится следить за ними самому. В случае исходного кода компилятор сам оповещает анализатор об изменениях (подписаться на которые можно, используя методы
CompilationStartAnalysisContext.Register*Action)Даже сейчас большинство разработчиков выбирают в качестве рабочей машины макбук, и исправление этой проблемы улучшило developer experience в том числе и для текущих сотрудников. Также для перехода оценивался полный набор задач разработчика, и сборка является лишь его частью.