Часто задаваемые вопросы | Лазурный

Примечание.

С 31 декабря 2022 г. расширение Microsoft Security Code Analysis (MSCA) отключено. MSCA заменяется расширением Microsoft Security DevOps Azure DevOps. Следуйте инструкциям в Настройка для установки и настройки расширения.

Общие вопросы и ответы

Можно ли установить расширение на экземпляре Azure DevOps Server (прежнее название — Visual Studio Team Foundation Server) вместо экземпляра Azure DevOps?

Нет. Расширение недоступно для скачивания и установки azure DevOps Server (ранее — Visual Studio Team Foundation Server).

Нужно ли выполнять анализ кода безопасности Майкрософт с помощью моей сборки?

Возможно. Это зависит от типа средства анализа. Исходный код может быть единственной необходимой вещью или выходными данными сборки.

Например, средство проверки учетных данных (CredScan) анализирует файлы в структуре папок репозитория кода. Из-за этого анализа можно запускать задачи сборки журналов безопасности CredScan и опубликовать журналы безопасности в автономной сборке, чтобы получить результаты.

Для других инструментов, таких как BinSkim, которые анализируют артефакты после сборки, сначала требуется сборка.

Можно ли разбить сборку при обнаружении результатов?

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

В пользовательском интерфейсе задачи post-Analysis можно разбить сборку, когда любой инструмент сообщает об ошибках только или как об ошибках, так и предупреждениях.

Как аргументы командной строки в Azure DevOps отличаются от этих аргументов в автономных классических средствах?

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

Заметные различия:

• Средства запускаются из исходной папки агента $(Build.SourcesDirectory) или из %BUILD_SOURCESDIRECTORY%. Примером является C:\agent_work\1\s.
• Пути в аргументах могут быть относительными к корню исходного каталога, указанного ранее. Пути также могут быть абсолютными. Абсолютные пути можно получить с помощью переменных сборки Azure DevOps или локального агента с известными расположениями развертывания локальных ресурсов.
• Средства автоматически предоставляют выходной путь к файлу или папке. Если вы предоставляете выходное расположение для задачи сборки, это расположение заменяется на путь к нашему известному расположению журналов в агенте сборки.
• Некоторые другие аргументы командной строки изменяются для некоторых инструментов. Одним из примеров является добавление или удаление параметров, которые не запускают графический интерфейс.

Можно ли запустить задачу сборки, например средство проверки учетных данных в нескольких репозиториях в сборке Azure DevOps?

Нет. Запуск средств безопасной разработки в нескольких репозиториях в одном конвейере не поддерживается.

Указанный выходной файл не создается или не удается найти указанный выходной файл.

Задачи сборки фильтруют некоторые входные данные пользователя. Для этого вопроса они обновляют расположение созданного выходного файла, чтобы быть общим расположением агента сборки. Дополнительные сведения об этом расположении см. в следующих статьях.

Где хранятся выходные файлы, созданные средствами?

Задачи сборки автоматически добавляют пути вывода в это хорошо известное расположение агента сборки: $(Agent.BuildDirectory)_sdt\logs. Так как мы стандартизируем это расположение, все команды, создающие или использующие журналы анализа кода, имеют доступ к выходным данным.

Можно ли ставить сборку в очередь для выполнения этих задач в размещенном агенте сборки?

Да. Все задачи и средства в расширении могут выполняться в размещенном агенте сборки.

Примечание.

Для задачи сборки сканера защиты от вредоносных программ требуется агент сборки с включенным Защитником Windows. Размещенная среда Visual Studio 2017 и более поздних версий предоставляет такой агент. Задача сборки не будет выполняться в размещенном агенте Visual Studio 2015.

Хотя подписи не могут быть обновлены для этих агентов, подписи всегда должны быть меньше трех часов.

Можно ли выполнять эти задачи сборки как часть конвейера выпуска, а не конвейер сборки?

В большинстве случаев да.

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

Откуда задачи сборки скачивают средства?

Задачи сборки могут скачать пакеты NuGet средств из веб-канала управления пакетами Azure DevOps. Задачи сборки также могут использовать диспетчер пакетов узлов, который должен быть предварительно установлен в агенте сборки. Примером такой установки является команда npm install tslint.

Какой эффект влияет на установку расширения в моей организации Azure DevOps?

После установки задачи сборки безопасности, предоставляемые расширением, становятся доступными всем пользователям в вашей организации. При создании или изменении Azure Pipeline эти задачи доступны в списке коллекций задач сборки. В противном случае установка расширения в организации Azure DevOps не влияет. Установка не изменяет параметры учетной записи, параметры проекта или конвейеры.

Изменяет ли установка расширения существующие Azure Pipelines?

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

Вопросы и ответы о конкретных задачах

Вопросы, относящиеся к задачам сборки, перечислены в этом разделе.

Сканер учетных данных

Каковы распространенные сценарии подавления и примеры?

Ниже приведены сведения о двух наиболее распространенных сценариях подавления.

Подавление всех вхождения заданного секрета в указанном пути

Хэш-ключ секрета из выходного файла CredScan необходим, как показано в следующем примере.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Предупреждение

Хэш-ключ создается частью соответствующего значения или содержимого файла. Любая редакция исходного кода может изменить хэш-ключ и отключить правило подавления.

Подавление всех секретов в указанном файле или подавление самого файла секретов

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

В следующих примерах показано, как отключить файл <InputPath>\src\JS\lib\angular.js

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

• <InputPath>\src\JS\lib\angular.js — подавляет файл в указанном пути.
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js — подавляет любой файл с тем же именем.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Предупреждение

Все будущие секреты, добавленные в файл, также будут автоматически подавляться.

Какие рекомендации по управлению секретами рекомендуется использовать?

Следующие ресурсы помогают безопасно управлять секретами и получать доступ к конфиденциальной информации из приложений:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• управляемое удостоверение службы Azure AD (MSI)
• Управляемые удостоверения для ресурсов Azure
• управляемых удостоверений в Службе приложений Azure и Функциях Azure
• библиотеки appAuthentication

Дополнительные сведения см. в записи блога безопасное управление секретами в облаке.

Можно ли написать собственные пользовательские поисковые средства?

Средство проверки учетных данных использует набор средств поиска контента, которые обычно определены в файле buildsearchers.xml. Файл содержит массив сериализованных XML-объектов, представляющих объект ContentSearcher. Программа распространяется с набором хорошо протестированных поисковых средств. Но вы также можете реализовать собственные пользовательские поисковые средства.

Средство поиска содержимого определяется следующим образом:

• Имя: описательное имя средства поиска, которое будет использоваться в выходных файлах средства проверки учетных данных. Мы рекомендуем использовать соглашение об именовании верблюгового регистра для имен поиска.

• RuleId: стабильный непрозрачный идентификатор средства поиска:

  • Средство поиска по умолчанию сканера учетных данных назначается значением ruleId, например CSCAN0010, CSCAN0020 или CSCAN0030. Последняя цифра зарезервирована для потенциального объединения или деления групп поиска по регулярным выражениям (regex).
  • Значение RuleId для настраиваемого поискового средства должно иметь собственное пространство имен. Примерами являются CSCAN-<пространство имен>0010, CSCAN-<пространство имен>0020 и пространство имен CSCAN-<>0030.
  • Полное имя средства поиска — это сочетание значения RuleId и имени средства поиска. Примеры включают CSCAN0010. KeyStoreFiles и CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: regex расширений файлов для проверки на наличие средства поиска.

• ContentSearchPatterns: массив строк, содержащих инструкции regex для сопоставления. Если шаблоны поиска не определены, возвращаются все файлы, соответствующие значению ResourceMatchPattern.

• ContentSearchFilters: массив строк, содержащих инструкции regex для фильтрации ложных срабатываний, определенных для поиска.

• MatchDetails: описательное сообщение, инструкции по устранению рисков или оба, добавляемые для каждого соответствия средства поиска.

• рекомендации: содержимое поля предложений для сопоставления с использованием формата отчета PREfast.

• серьезности: целое число, которое отражает уровень серьезности проблемы. Самый высокий уровень серьезности имеет значение 1.

  установки средства проверки учетных данных

Анализаторы Roslyn

Каковы распространенные ошибки при использовании задачи Roslyn Analyzers?

Проект был восстановлен с помощью неправильной версии Microsoft.NETCore.App

Полное сообщение об ошибке:

"Ошибка: проект был восстановлен с помощью Microsoft.NETCore.App версии x.x.x, но с текущими параметрами будет использоваться версия y.y.y.y. Чтобы устранить эту проблему, убедитесь, что те же параметры используются для восстановления и последующих операций, таких как сборка или публикация. Как правило, эта проблема может возникать, если свойство RuntimeIdentifier задано во время сборки или публикации, но не во время восстановления".

Так как задачи Roslyn Analyzers выполняются в процессе компиляции, исходное дерево на компьютере сборки должно находиться в состоянии сборки.

Шаг между основными сборками и шагами анализаторов Roslyn может поместить исходное дерево в состояние, которое предотвращает сборку. Этот дополнительный шаг, вероятно, dotnet.exe опубликовать. Попробуйте дублировать шаг, который выполняет восстановление NuGet непосредственно перед шагом Анализаторов Roslyn. Этот повторяющийся шаг может вернуть исходное дерево в состояние сборки.

csc.exe не удается создать экземпляр анализатора

Полное сообщение об ошибке:

""csc.exe" завершен с кодом ошибки 1 - экземпляр анализатора AAAA невозможно создать из C:\BBBB.dll: не удалось загрузить файл или сборку Microsoft.CodeAnalysis, Version=X.X.X.X., Culture=neutral, PublicKeyToken=31bf3856ad36ad364e35' или одно из зависимостей. Система не может найти указанный файл".

Убедитесь, что компилятор поддерживает анализаторы Roslyn. Выполнение команды csc.exe /version должно сообщать о значении версии 2.6 или более поздней версии.

Иногда CSPROJ-файл может переопределить установку Visual Studio компьютера сборки, ссылаясь на пакет из Microsoft.Net.Compilers. Если вы не планируете использовать определенную версию компилятора, удалите ссылки на Microsoft.Net.Compilers. В противном случае убедитесь, что версия указанного пакета также имеет значение 2.6 или более поздней версии.

Попробуйте получить путь журнала ошибок, указанный в параметре csc.exe /errorlog. Параметр и путь отображаются в журнале для задачи сборки Roslyn Analyzers. Они могут выглядеть примерно так, как /errorlog:F:\ts-services-123_work\\456\s\Some\Project\Code\Code.csproj.sarif

Версия компилятора C# не является достаточно последней.

Чтобы получить последние версии компилятора C#, перейдите к Microsoft.Net.Compilers. Чтобы получить установленную версию, запустите csc.exe /version в командной строке. Убедитесь, что вы ссылаетесь на пакет NuGet Microsoft.Net.Compilers, который является версией 2.6 или более поздней.

Журналы MSBuild и VSBuild не найдены

Задача сборки Roslyn Analyzers должна запрашивать Azure DevOps для журнала MSBuild из задачи сборки MSBuild. Если задача анализатора выполняется сразу после задачи MSBuild, журнал пока не будет доступен. Поместите другие задачи между задачей MSBuild и задачей Roslyn Analyzers. Примерами других задач являются BinSkim и сканер защиты от вредоносных программ.

Дальнейшие действия

Если вам нужна дополнительная помощь, служба поддержки анализа кода безопасности Майкрософт доступна в понедельник до пятницы с 9:00 по 5:00 по тихоокеанскому стандартному времени.

• Подключение. Ознакомьтесь с нашей документацией по подключению

• Поддержка: отправка электронной почты нашей команде в службу поддержки службы "Анализ кода Майкрософт"

Примечание.

С 31 декабря 2022 г. расширение Microsoft Security Code Analysis (MSCA) отключено. MSCA заменяется расширением Microsoft Security DevOps Azure DevOps. Следуйте инструкциям в Настройка для установки и настройки расширения.

Нет. Расширение недоступно для скачивания и установки azure DevOps Server (ранее — Visual Studio Team Foundation Server).

Возможно. Это зависит от типа средства анализа. Исходный код может быть единственной необходимой вещью или выходными данными сборки.

Например, средство проверки учетных данных (CredScan) анализирует файлы в структуре папок репозитория кода. Из-за этого анализа можно запускать задачи сборки журналов безопасности CredScan и опубликовать журналы безопасности в автономной сборке, чтобы получить результаты.

Для других инструментов, таких как BinSkim, которые анализируют артефакты после сборки, сначала требуется сборка.

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

В пользовательском интерфейсе задачи post-Analysis можно разбить сборку, когда любой инструмент сообщает об ошибках только или как об ошибках, так и предупреждениях.

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

Заметные различия:

• Средства запускаются из исходной папки агента $(Build.SourcesDirectory) или из %BUILD_SOURCESDIRECTORY%. Примером является C:\agent_work\1\s.
• Пути в аргументах могут быть относительными к корню исходного каталога, указанного ранее. Пути также могут быть абсолютными. Абсолютные пути можно получить с помощью переменных сборки Azure DevOps или локального агента с известными расположениями развертывания локальных ресурсов.
• Средства автоматически предоставляют выходной путь к файлу или папке. Если вы предоставляете выходное расположение для задачи сборки, это расположение заменяется на путь к нашему известному расположению журналов в агенте сборки.
• Некоторые другие аргументы командной строки изменяются для некоторых инструментов. Одним из примеров является добавление или удаление параметров, которые не запускают графический интерфейс.

Нет. Запуск средств безопасной разработки в нескольких репозиториях в одном конвейере не поддерживается.

Задачи сборки фильтруют некоторые входные данные пользователя. Для этого вопроса они обновляют расположение созданного выходного файла, чтобы быть общим расположением агента сборки. Дополнительные сведения об этом расположении см. в следующих статьях.

Задачи сборки автоматически добавляют пути вывода в это хорошо известное расположение агента сборки: $(Agent.BuildDirectory)_sdt\logs. Так как мы стандартизируем это расположение, все команды, создающие или использующие журналы анализа кода, имеют доступ к выходным данным.

Да. Все задачи и средства в расширении могут выполняться в размещенном агенте сборки.

Примечание.

Для задачи сборки сканера защиты от вредоносных программ требуется агент сборки с включенным Защитником Windows. Размещенная среда Visual Studio 2017 и более поздних версий предоставляет такой агент. Задача сборки не будет выполняться в размещенном агенте Visual Studio 2015.

Хотя подписи не могут быть обновлены для этих агентов, подписи всегда должны быть меньше трех часов.

В большинстве случаев да.

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

Задачи сборки могут скачать пакеты NuGet средств из веб-канала управления пакетами Azure DevOps. Задачи сборки также могут использовать диспетчер пакетов узлов, который должен быть предварительно установлен в агенте сборки. Примером такой установки является команда npm install tslint.

После установки задачи сборки безопасности, предоставляемые расширением, становятся доступными всем пользователям в вашей организации. При создании или изменении Azure Pipeline эти задачи доступны в списке коллекций задач сборки. В противном случае установка расширения в организации Azure DevOps не влияет. Установка не изменяет параметры учетной записи, параметры проекта или конвейеры.

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

Вопросы и ответы о конкретных задачах

Вопросы, относящиеся к задачам сборки, перечислены в этом разделе.

Ниже приведены сведения о двух наиболее распространенных сценариях подавления.

Подавление всех вхождения заданного секрета в указанном пути

Хэш-ключ секрета из выходного файла CredScan необходим, как показано в следующем примере.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Предупреждение

Хэш-ключ создается частью соответствующего значения или содержимого файла. Любая редакция исходного кода может изменить хэш-ключ и отключить правило подавления.

Подавление всех секретов в указанном файле или подавление самого файла секретов

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

В следующих примерах показано, как отключить файл <InputPath>\src\JS\lib\angular.js

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

• <InputPath>\src\JS\lib\angular.js — подавляет файл в указанном пути.
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js — подавляет любой файл с тем же именем.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Предупреждение

Все будущие секреты, добавленные в файл, также будут автоматически подавляться.

Следующие ресурсы помогают безопасно управлять секретами и получать доступ к конфиденциальной информации из приложений:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• управляемое удостоверение службы Azure AD (MSI)
• Управляемые удостоверения для ресурсов Azure
• управляемых удостоверений в Службе приложений Azure и Функциях Azure
• библиотеки appAuthentication

Дополнительные сведения см. в записи блога безопасное управление секретами в облаке.

Средство проверки учетных данных использует набор средств поиска контента, которые обычно определены в файле buildsearchers.xml. Файл содержит массив сериализованных XML-объектов, представляющих объект ContentSearcher. Программа распространяется с набором хорошо протестированных поисковых средств. Но вы также можете реализовать собственные пользовательские поисковые средства.

Средство поиска содержимого определяется следующим образом:

• Имя: описательное имя средства поиска, которое будет использоваться в выходных файлах средства проверки учетных данных. Мы рекомендуем использовать соглашение об именовании верблюгового регистра для имен поиска.

• RuleId: стабильный непрозрачный идентификатор средства поиска:

  • Средство поиска по умолчанию сканера учетных данных назначается значением ruleId, например CSCAN0010, CSCAN0020 или CSCAN0030. Последняя цифра зарезервирована для потенциального объединения или деления групп поиска по регулярным выражениям (regex).
  • Значение RuleId для настраиваемого поискового средства должно иметь собственное пространство имен. Примерами являются CSCAN-<пространство имен>0010, CSCAN-<пространство имен>0020 и пространство имен CSCAN-<>0030.
  • Полное имя средства поиска — это сочетание значения RuleId и имени средства поиска. Примеры включают CSCAN0010. KeyStoreFiles и CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: regex расширений файлов для проверки на наличие средства поиска.

• ContentSearchPatterns: массив строк, содержащих инструкции regex для сопоставления. Если шаблоны поиска не определены, возвращаются все файлы, соответствующие значению ResourceMatchPattern.

• ContentSearchFilters: массив строк, содержащих инструкции regex для фильтрации ложных срабатываний, определенных для поиска.

• MatchDetails: описательное сообщение, инструкции по устранению рисков или оба, добавляемые для каждого соответствия средства поиска.

• рекомендации: содержимое поля предложений для сопоставления с использованием формата отчета PREfast.

• серьезности: целое число, которое отражает уровень серьезности проблемы. Самый высокий уровень серьезности имеет значение 1.

  установки средства проверки учетных данных

Проект был восстановлен с помощью неправильной версии Microsoft.NETCore.App

Полное сообщение об ошибке:

"Ошибка: проект был восстановлен с помощью Microsoft.NETCore.App версии x.x.x, но с текущими параметрами будет использоваться версия y.y.y.y. Чтобы устранить эту проблему, убедитесь, что те же параметры используются для восстановления и последующих операций, таких как сборка или публикация. Как правило, эта проблема может возникать, если свойство RuntimeIdentifier задано во время сборки или публикации, но не во время восстановления".

Так как задачи Roslyn Analyzers выполняются в процессе компиляции, исходное дерево на компьютере сборки должно находиться в состоянии сборки.

Шаг между основными сборками и шагами анализаторов Roslyn может поместить исходное дерево в состояние, которое предотвращает сборку. Этот дополнительный шаг, вероятно, dotnet.exe опубликовать. Попробуйте дублировать шаг, который выполняет восстановление NuGet непосредственно перед шагом Анализаторов Roslyn. Этот повторяющийся шаг может вернуть исходное дерево в состояние сборки.

csc.exe не удается создать экземпляр анализатора

Полное сообщение об ошибке:

""csc.exe" завершен с кодом ошибки 1 - экземпляр анализатора AAAA невозможно создать из C:\BBBB.dll: не удалось загрузить файл или сборку Microsoft.CodeAnalysis, Version=X.X.X.X., Culture=neutral, PublicKeyToken=31bf3856ad36ad364e35' или одно из зависимостей. Система не может найти указанный файл".

Убедитесь, что компилятор поддерживает анализаторы Roslyn. Выполнение команды csc.exe /version должно сообщать о значении версии 2.6 или более поздней версии.

Иногда CSPROJ-файл может переопределить установку Visual Studio компьютера сборки, ссылаясь на пакет из Microsoft.Net.Compilers. Если вы не планируете использовать определенную версию компилятора, удалите ссылки на Microsoft.Net.Compilers. В противном случае убедитесь, что версия указанного пакета также имеет значение 2.6 или более поздней версии.

Попробуйте получить путь журнала ошибок, указанный в параметре csc.exe /errorlog. Параметр и путь отображаются в журнале для задачи сборки Roslyn Analyzers. Они могут выглядеть примерно так, как /errorlog:F:\ts-services-123_work\\456\s\Some\Project\Code\Code.csproj.sarif

Версия компилятора C# не является достаточно последней.

Чтобы получить последние версии компилятора C#, перейдите к Microsoft.Net.Compilers. Чтобы получить установленную версию, запустите csc.exe /version в командной строке. Убедитесь, что вы ссылаетесь на пакет NuGet Microsoft.Net.Compilers, который является версией 2.6 или более поздней.

Журналы MSBuild и VSBuild не найдены

Задача сборки Roslyn Analyzers должна запрашивать Azure DevOps для журнала MSBuild из задачи сборки MSBuild. Если задача анализатора выполняется сразу после задачи MSBuild, журнал пока не будет доступен. Поместите другие задачи между задачей MSBuild и задачей Roslyn Analyzers. Примерами других задач являются BinSkim и сканер защиты от вредоносных программ.

Дальнейшие действия

Если вам нужна дополнительная помощь, служба поддержки анализа кода безопасности Майкрософт доступна в понедельник до пятницы с 9:00 по 5:00 по тихоокеанскому стандартному времени.

• Подключение. Ознакомьтесь с нашей документацией по подключению

• Поддержка: отправка электронной почты нашей команде в службу поддержки службы "Анализ кода Майкрософт"