Perguntas frequentes | Azure

Observação

A partir de 31 de dezembro de 2022, a extensão Microsoft Security Code Analysis (MSCA) será desativada. MSCA é substituído pelo Microsoft Security DevOps Azure DevOps extensão. Siga as instruções em Configurar para instalar e configurar a extensão.

FAQ Gerais

Posso instalar a extensão na minha instância do Azure DevOps Server (anteriormente Visual Studio Team Foundation Server) em vez de em uma instância do Azure DevOps?

Não. A extensão não está disponível para download e instalação para o Azure DevOps Server (anteriormente Visual Studio Team Foundation Server).

Tenho de executar a Análise de Código de Segurança da Microsoft com a minha compilação?

Talvez. Depende do tipo de ferramenta de análise. O código-fonte pode ser a única coisa necessária, ou a saída da compilação pode ser necessária.

Por exemplo, o Credential Scanner (CredScan) analisa arquivos dentro da estrutura de pastas do repositório de código. Devido a essa análise, você pode executar as tarefas de compilação CredScan e Publish Security Analysis Logs em uma compilação autônoma para obter resultados.

Para outras ferramentas como BinSkim que analisam artefatos pós-compilação, a compilação é necessária primeiro.

Posso quebrar minha compilação quando os resultados forem encontrados?

Sim. Você pode introduzir uma quebra de compilação quando qualquer ferramenta relatar um problema ou problema em seu arquivo de log. Adicione a tarefa de compilação Post-Analysis e marque a caixa de seleção para qualquer ferramenta para a qual você deseja interromper a compilação.

Na interface do usuário da tarefa Pós-análise, você pode optar por interromper a compilação quando qualquer ferramenta relatar apenas erros ou erros e avisos.

Como os argumentos de linha de comando no Azure DevOps diferem desses argumentos nas ferramentas de área de trabalho autônomas?

Normalmente, as tarefas de compilação do Azure DevOps são wrappers diretos em torno dos argumentos de linha de comando das ferramentas de segurança. Você pode passar como argumentos para uma tarefa de compilação qualquer coisa que normalmente passe para uma ferramenta de linha de comando.

Diferenças notáveis:

• As ferramentas são executadas a partir da pasta de origem do agente $(Build.SourcesDirectory) ou de %BUILD_SOURCESDIRECTORY%. Um exemplo é C:\agent_work\1\s.
• Os caminhos nos argumentos podem ser relativos à raiz do diretório de origem listado anteriormente. Os caminhos também podem ser absolutos. Você obtém caminhos absolutos usando as Variáveis de Compilação do Azure DevOps ou executando um agente local com locais de implantação conhecidos de recursos locais.
• As ferramentas fornecem automaticamente um caminho ou pasta de arquivo de saída. Se você fornecer um local de saída para uma tarefa de compilação, esse local será substituído por um caminho para nosso local conhecido de logs no agente de compilação
• Alguns outros argumentos de linha de comando são alterados para algumas ferramentas. Um exemplo é a adição ou remoção de opções que garantem que nenhuma GUI seja iniciada.

Posso executar uma tarefa de compilação como o Verificador de Credenciais em vários repositórios em uma Compilação do Azure DevOps?

Não. Não há suporte para a execução das ferramentas de desenvolvimento seguro em vários repositórios em um único pipeline.

O arquivo de saída que especifiquei não está sendo criado ou não consigo encontrar o arquivo de saída especificado

As tarefas de compilação filtram algumas entradas do usuário. Para essa pergunta especificamente, eles atualizam o local do arquivo de saída gerado para ser um local comum no agente de compilação. Para obter mais informações sobre esse local, consulte as perguntas a seguir.

Onde são salvos os arquivos de saída gerados pelas ferramentas?

As tarefas de compilação adicionam automaticamente caminhos de saída a esse local conhecido no agente de compilação: $(Agent.BuildDirectory)_sdt\logs. Como padronizamos nesse local, todas as equipes que produzem ou consomem logs de análise de código têm acesso à saída.

Posso enfileirar uma compilação para executar essas tarefas em um agente de compilação hospedado?

Sim. Todas as tarefas e ferramentas na extensão podem ser executadas em um agente de compilação hospedado.

Observação

A tarefa de compilação do Anti-Malware Scanner requer um agente de compilação com o Windows Defender habilitado. O Visual Studio 2017 hospedado e posterior fornece esse agente. A tarefa de compilação não será executada no agente hospedado do Visual Studio 2015.

Embora as assinaturas não possam ser atualizadas nesses agentes, as assinaturas devem ter sempre menos de três horas.

Posso executar essas tarefas de compilação como parte de um pipeline de liberação em vez de um pipeline de compilação?

Na maioria dos casos, sim.

No entanto, o Azure DevOps não dá suporte à execução de tarefas dentro de pipelines de liberação quando essas tarefas publicam artefatos. Essa falta de suporte impede que a tarefa Publicar logs de análise de segurança seja executada com êxito em um pipeline de versão. Em vez disso, a tarefa falha com uma mensagem de erro descritiva.

De onde as tarefas de compilação baixam as ferramentas?

As tarefas de compilação podem baixar os pacotes NuGet das ferramentas do feed Azure DevOps Package Management. As tarefas de compilação também podem usar o Gerenciador de Pacotes de Nó, que deve ser pré-instalado no agente de compilação. Um exemplo de tal instalação é o comando npm install tslint.

Que efeito a instalação da extensão tem na minha organização do Azure DevOps?

Após a instalação, as tarefas de compilação de segurança fornecidas pela extensão ficam disponíveis para todos os usuários em sua organização. Quando você cria ou edita um Pipeline do Azure, essas tarefas ficam disponíveis na lista de coleta de tarefas de compilação. Caso contrário, a instalação da extensão em sua organização do Azure DevOps não terá efeito. A instalação não modifica nenhuma configuração de conta, configurações de projeto ou pipelines.

A instalação da extensão modifica meus Pipelines do Azure existentes?

Não. A instalação da extensão torna as tarefas de compilação de segurança disponíveis para adição aos seus pipelines. Você ainda é obrigado a adicionar ou atualizar definições de compilação, para que as ferramentas possam trabalhar com seu processo de compilação.

Perguntas frequentes específicas da tarefa

Perguntas específicas para tarefas de compilação estão listadas nesta seção.

Scanner de credenciais

Quais são os cenários e exemplos comuns de supressão?

Aqui estão detalhes de dois dos cenários de supressão mais comuns.

Para suprimir todas as ocorrências de um determinado segredo dentro do caminho especificado

A chave de hash do segredo do arquivo de saída CredScan é necessária, conforme mostrado no exemplo a seguir.

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

Advertência

A chave hash é gerada por uma parte do valor correspondente ou do conteúdo do arquivo. Qualquer revisão do código-fonte pode alterar a chave de hash e desativar a regra de supressão.

Para suprimir todos os segredos em um arquivo especificado ou suprimir o próprio arquivo de segredos

A expressão de arquivo pode ser um nome de arquivo. Também pode ser a parte basename de um caminho de arquivo completo ou um nome de arquivo. Não há suporte para curingas.

Os exemplos a seguir mostram como suprimir o arquivo <InputPath>\src\JS\lib\angular.js

Exemplos de regras de supressão válidas:

• <InputPath>\src\JS\lib\angular.js - suprime o arquivo no caminho especificado
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js - suprime qualquer ficheiro com o mesmo nome

{
    "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"
    }
  ]
}

Advertência

Todos os segredos futuros adicionados ao arquivo também serão suprimidos automaticamente.

Quais são as diretrizes recomendadas para gerenciar segredos?

Os seguintes recursos ajudam você a gerenciar segredos com segurança e acessar informações confidenciais de dentro de seus aplicativos:

• Azure Key Vault
• do Azure Ative Directory (Azure AD)
• de Identidade de Serviço Gerenciado (MSI) do Azure AD
• Identidades geridas para os recursos do Azure
• identidades gerenciadas no Serviço de Aplicativo do Azure e no Azure Functions
• biblioteca AppAuthentication

Para obter mais informações, consulte a postagem do blog Gerenciando segredos com segurança na nuvem.

Posso escrever os meus próprios pesquisadores personalizados?

O Credential Scanner depende de um conjunto de pesquisadores de conteúdo que são comumente definidos no arquivo buildsearchers.xml. O arquivo contém uma matriz de objetos serializados XML que representam um objeto ContentSearcher. O programa é distribuído com um conjunto de pesquisadores bem testados. Mas você também pode implementar seus próprios pesquisadores personalizados.

Um pesquisador de conteúdo é definido da seguinte forma:

• Nome: O nome do pesquisador descritivo a ser usado nos arquivos de saída do Credential Scanner. Recomendamos que você use a convenção de nomenclatura camel-case para nomes de buscadores.

• RuleId: O ID opaco estável do pesquisador:

  • Um pesquisador padrão do Credential Scanner recebe um valor RuleId como CSCAN0010, CSCAN0020 ou CSCAN0030. O último dígito é reservado para potencialmente mesclar ou dividir grupos de pesquisadores por meio de expressões regulares (regex).
  • O valor RuleId para um pesquisador personalizado deve ter seu próprio namespace. Os exemplos incluem CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 e CSCAN-<Namespace>0030.
  • Um nome de pesquisador totalmente qualificado é a combinação de um valor de RuleId e um nome de pesquisador. Exemplos incluem CSCAN0010. KeyStoreFiles e CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex de extensões de arquivo para verificar contra o pesquisador.

• ContentSearchPatterns: Uma matriz de cadeias de caracteres contendo instruções regex para corresponder. Se nenhum padrão de pesquisa for definido, todos os arquivos correspondentes ao valor ResourceMatchPattern serão retornados.

• ContentSearchFilters: Uma matriz de cadeias de caracteres contendo instruções regex para filtrar falsos positivos específicos do pesquisador.

• MatchDetails: Uma mensagem descritiva, instruções de mitigação ou ambas a serem adicionadas para cada correspondência do pesquisador.

• Recomendação: O conteúdo do campo de sugestões para uma partida usando o formato de relatório PREfast.

• de gravidade: um número inteiro que reflete o nível de gravidade de um problema. O nível de gravidade mais elevado tem o valor 1.

  

Analisadores Roslyn

Quais são os erros comuns ao usar a tarefa Roslyn Analyzers?

O projeto foi restaurado usando uma versão Microsoft.NETCore.App errada

A mensagem de erro completa:

"Erro: O projeto foi restaurado usando Microsoft.NETCore.App versão x.x.x, mas com as configurações atuais, a versão y.y.y seria usada em vez disso. Para resolver esse problema, certifique-se de que as mesmas configurações são usadas para restauração e para operações subsequentes, como compilar ou publicar. Normalmente, esse problema pode ocorrer se a propriedade RuntimeIdentifier for definida durante a compilação ou publicação, mas não durante a restauração."

Como as tarefas do Roslyn Analyzers são executadas como parte da compilação, a árvore de código-fonte na máquina de compilação deve estar em um estado edificável.

Uma etapa entre a compilação principal e as etapas do Roslyn Analyzers pode ter colocado a árvore de origem em um estado que impede a construção. Este passo extra é provavelmente dotnet.exe publicar. Tente duplicar a etapa que faz uma restauração do NuGet logo antes da etapa Roslyn Analyzers. Esta etapa duplicada pode colocar a árvore de origem de volta em um estado edificável.

csc.exe não é possível criar uma instância do analisador

A mensagem de erro completa:

"'csc.exe' saiu com o código de erro 1 -- Uma instância do analisador AAAA não pode ser criada a partir de C:\BBBB.dll : Não foi possível carregar o arquivo ou assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ou uma de suas dependências. O sistema não consegue encontrar o ficheiro especificado."

Certifique-se de que seu compilador suporte Roslyn Analyzers. A execução do comando csc.exe /version deve relatar um valor de versão 2.6 ou posterior.

Às vezes, um arquivo .csproj pode substituir a instalação do Visual Studio da máquina de compilação fazendo referência a um pacote de Microsoft.Net.Compilers. Se você não pretende usar uma versão específica do compilador, remova as referências a Microsoft.Net.Compilers. Caso contrário, certifique-se de que a versão do pacote referenciado também é 2.6 ou posterior.

Tente obter o caminho do log de erros, que é especificado na opção csc.exe /errorlog. A opção e o caminho aparecem no log da tarefa de compilação do Roslyn Analyzers. Eles podem se parecer com /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

A versão do compilador C# não é recente o suficiente

Para obter as versões mais recentes do compilador C#, vá para Microsoft.Net.Compilers. Para obter a versão instalada, execute csc.exe /version em um prompt de comando. Certifique-se de fazer referência a um pacote NuGet Microsoft.Net.Compilers versão 2.6 ou posterior.

Os logs MSBuild e VSBuild não foram encontrados

A tarefa de compilação do Roslyn Analyzers deve consultar o Azure DevOps para o log do MSBuild a partir da tarefa de compilação do MSBuild. Se a tarefa do analisador for executada imediatamente após a tarefa do MSBuild, o log ainda não estará disponível. Coloque outras tarefas entre a tarefa MSBuild e a tarefa Roslyn Analyzers. Exemplos de outras tarefas incluem BinSkim e Anti-Malware Scanner.

Próximos passos

Se precisar de assistência adicional, o Suporte de Análise de Código de Segurança da Microsoft está disponível de segunda a sexta-feira, das 9h00 às 17h00, horário padrão do Pacífico.

• Onboarding: Consulte nossa documentação de Onboarding

• Suporte: Envie um e-mail para nossa equipe em de Suporte de Análise de Código de Segurança da Microsoft

Observação

A partir de 31 de dezembro de 2022, a extensão Microsoft Security Code Analysis (MSCA) será desativada. MSCA é substituído pelo Microsoft Security DevOps Azure DevOps extensão. Siga as instruções em Configurar para instalar e configurar a extensão.

Não. A extensão não está disponível para download e instalação para o Azure DevOps Server (anteriormente Visual Studio Team Foundation Server).

Talvez. Depende do tipo de ferramenta de análise. O código-fonte pode ser a única coisa necessária, ou a saída da compilação pode ser necessária.

Por exemplo, o Credential Scanner (CredScan) analisa arquivos dentro da estrutura de pastas do repositório de código. Devido a essa análise, você pode executar as tarefas de compilação CredScan e Publish Security Analysis Logs em uma compilação autônoma para obter resultados.

Para outras ferramentas como BinSkim que analisam artefatos pós-compilação, a compilação é necessária primeiro.

Sim. Você pode introduzir uma quebra de compilação quando qualquer ferramenta relatar um problema ou problema em seu arquivo de log. Adicione a tarefa de compilação Post-Analysis e marque a caixa de seleção para qualquer ferramenta para a qual você deseja interromper a compilação.

Na interface do usuário da tarefa Pós-análise, você pode optar por interromper a compilação quando qualquer ferramenta relatar apenas erros ou erros e avisos.

Normalmente, as tarefas de compilação do Azure DevOps são wrappers diretos em torno dos argumentos de linha de comando das ferramentas de segurança. Você pode passar como argumentos para uma tarefa de compilação qualquer coisa que normalmente passe para uma ferramenta de linha de comando.

Diferenças notáveis:

• As ferramentas são executadas a partir da pasta de origem do agente $(Build.SourcesDirectory) ou de %BUILD_SOURCESDIRECTORY%. Um exemplo é C:\agent_work\1\s.
• Os caminhos nos argumentos podem ser relativos à raiz do diretório de origem listado anteriormente. Os caminhos também podem ser absolutos. Você obtém caminhos absolutos usando as Variáveis de Compilação do Azure DevOps ou executando um agente local com locais de implantação conhecidos de recursos locais.
• As ferramentas fornecem automaticamente um caminho ou pasta de arquivo de saída. Se você fornecer um local de saída para uma tarefa de compilação, esse local será substituído por um caminho para nosso local conhecido de logs no agente de compilação
• Alguns outros argumentos de linha de comando são alterados para algumas ferramentas. Um exemplo é a adição ou remoção de opções que garantem que nenhuma GUI seja iniciada.

Não. Não há suporte para a execução das ferramentas de desenvolvimento seguro em vários repositórios em um único pipeline.

As tarefas de compilação filtram algumas entradas do usuário. Para essa pergunta especificamente, eles atualizam o local do arquivo de saída gerado para ser um local comum no agente de compilação. Para obter mais informações sobre esse local, consulte as perguntas a seguir.

As tarefas de compilação adicionam automaticamente caminhos de saída a esse local conhecido no agente de compilação: $(Agent.BuildDirectory)_sdt\logs. Como padronizamos nesse local, todas as equipes que produzem ou consomem logs de análise de código têm acesso à saída.

Sim. Todas as tarefas e ferramentas na extensão podem ser executadas em um agente de compilação hospedado.

Observação

A tarefa de compilação do Anti-Malware Scanner requer um agente de compilação com o Windows Defender habilitado. O Visual Studio 2017 hospedado e posterior fornece esse agente. A tarefa de compilação não será executada no agente hospedado do Visual Studio 2015.

Embora as assinaturas não possam ser atualizadas nesses agentes, as assinaturas devem ter sempre menos de três horas.

Na maioria dos casos, sim.

No entanto, o Azure DevOps não dá suporte à execução de tarefas dentro de pipelines de liberação quando essas tarefas publicam artefatos. Essa falta de suporte impede que a tarefa Publicar logs de análise de segurança seja executada com êxito em um pipeline de versão. Em vez disso, a tarefa falha com uma mensagem de erro descritiva.

As tarefas de compilação podem baixar os pacotes NuGet das ferramentas do feed Azure DevOps Package Management. As tarefas de compilação também podem usar o Gerenciador de Pacotes de Nó, que deve ser pré-instalado no agente de compilação. Um exemplo de tal instalação é o comando npm install tslint.

Após a instalação, as tarefas de compilação de segurança fornecidas pela extensão ficam disponíveis para todos os usuários em sua organização. Quando você cria ou edita um Pipeline do Azure, essas tarefas ficam disponíveis na lista de coleta de tarefas de compilação. Caso contrário, a instalação da extensão em sua organização do Azure DevOps não terá efeito. A instalação não modifica nenhuma configuração de conta, configurações de projeto ou pipelines.

Não. A instalação da extensão torna as tarefas de compilação de segurança disponíveis para adição aos seus pipelines. Você ainda é obrigado a adicionar ou atualizar definições de compilação, para que as ferramentas possam trabalhar com seu processo de compilação.

Perguntas frequentes específicas da tarefa

Perguntas específicas para tarefas de compilação estão listadas nesta seção.

Aqui estão detalhes de dois dos cenários de supressão mais comuns.

Para suprimir todas as ocorrências de um determinado segredo dentro do caminho especificado

A chave de hash do segredo do arquivo de saída CredScan é necessária, conforme mostrado no exemplo a seguir.

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

Advertência

A chave hash é gerada por uma parte do valor correspondente ou do conteúdo do arquivo. Qualquer revisão do código-fonte pode alterar a chave de hash e desativar a regra de supressão.

Para suprimir todos os segredos em um arquivo especificado ou suprimir o próprio arquivo de segredos

A expressão de arquivo pode ser um nome de arquivo. Também pode ser a parte basename de um caminho de arquivo completo ou um nome de arquivo. Não há suporte para curingas.

Os exemplos a seguir mostram como suprimir o arquivo <InputPath>\src\JS\lib\angular.js

Exemplos de regras de supressão válidas:

• <InputPath>\src\JS\lib\angular.js - suprime o arquivo no caminho especificado
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js - suprime qualquer ficheiro com o mesmo nome

{
    "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"
    }
  ]
}

Advertência

Todos os segredos futuros adicionados ao arquivo também serão suprimidos automaticamente.

Os seguintes recursos ajudam você a gerenciar segredos com segurança e acessar informações confidenciais de dentro de seus aplicativos:

• Azure Key Vault
• do Azure Ative Directory (Azure AD)
• de Identidade de Serviço Gerenciado (MSI) do Azure AD
• Identidades geridas para os recursos do Azure
• identidades gerenciadas no Serviço de Aplicativo do Azure e no Azure Functions
• biblioteca AppAuthentication

Para obter mais informações, consulte a postagem do blog Gerenciando segredos com segurança na nuvem.

O Credential Scanner depende de um conjunto de pesquisadores de conteúdo que são comumente definidos no arquivo buildsearchers.xml. O arquivo contém uma matriz de objetos serializados XML que representam um objeto ContentSearcher. O programa é distribuído com um conjunto de pesquisadores bem testados. Mas você também pode implementar seus próprios pesquisadores personalizados.

Um pesquisador de conteúdo é definido da seguinte forma:

• Nome: O nome do pesquisador descritivo a ser usado nos arquivos de saída do Credential Scanner. Recomendamos que você use a convenção de nomenclatura camel-case para nomes de buscadores.

• RuleId: O ID opaco estável do pesquisador:

  • Um pesquisador padrão do Credential Scanner recebe um valor RuleId como CSCAN0010, CSCAN0020 ou CSCAN0030. O último dígito é reservado para potencialmente mesclar ou dividir grupos de pesquisadores por meio de expressões regulares (regex).
  • O valor RuleId para um pesquisador personalizado deve ter seu próprio namespace. Os exemplos incluem CSCAN-<Namespace>0010, CSCAN-<Namespace>0020 e CSCAN-<Namespace>0030.
  • Um nome de pesquisador totalmente qualificado é a combinação de um valor de RuleId e um nome de pesquisador. Exemplos incluem CSCAN0010. KeyStoreFiles e CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex de extensões de arquivo para verificar contra o pesquisador.

• ContentSearchPatterns: Uma matriz de cadeias de caracteres contendo instruções regex para corresponder. Se nenhum padrão de pesquisa for definido, todos os arquivos correspondentes ao valor ResourceMatchPattern serão retornados.

• ContentSearchFilters: Uma matriz de cadeias de caracteres contendo instruções regex para filtrar falsos positivos específicos do pesquisador.

• MatchDetails: Uma mensagem descritiva, instruções de mitigação ou ambas a serem adicionadas para cada correspondência do pesquisador.

• Recomendação: O conteúdo do campo de sugestões para uma partida usando o formato de relatório PREfast.

• de gravidade: um número inteiro que reflete o nível de gravidade de um problema. O nível de gravidade mais elevado tem o valor 1.

  

O projeto foi restaurado usando uma versão Microsoft.NETCore.App errada

A mensagem de erro completa:

"Erro: O projeto foi restaurado usando Microsoft.NETCore.App versão x.x.x, mas com as configurações atuais, a versão y.y.y seria usada em vez disso. Para resolver esse problema, certifique-se de que as mesmas configurações são usadas para restauração e para operações subsequentes, como compilar ou publicar. Normalmente, esse problema pode ocorrer se a propriedade RuntimeIdentifier for definida durante a compilação ou publicação, mas não durante a restauração."

Como as tarefas do Roslyn Analyzers são executadas como parte da compilação, a árvore de código-fonte na máquina de compilação deve estar em um estado edificável.

Uma etapa entre a compilação principal e as etapas do Roslyn Analyzers pode ter colocado a árvore de origem em um estado que impede a construção. Este passo extra é provavelmente dotnet.exe publicar. Tente duplicar a etapa que faz uma restauração do NuGet logo antes da etapa Roslyn Analyzers. Esta etapa duplicada pode colocar a árvore de origem de volta em um estado edificável.

csc.exe não é possível criar uma instância do analisador

A mensagem de erro completa:

"'csc.exe' saiu com o código de erro 1 -- Uma instância do analisador AAAA não pode ser criada a partir de C:\BBBB.dll : Não foi possível carregar o arquivo ou assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ou uma de suas dependências. O sistema não consegue encontrar o ficheiro especificado."

Certifique-se de que seu compilador suporte Roslyn Analyzers. A execução do comando csc.exe /version deve relatar um valor de versão 2.6 ou posterior.

Às vezes, um arquivo .csproj pode substituir a instalação do Visual Studio da máquina de compilação fazendo referência a um pacote de Microsoft.Net.Compilers. Se você não pretende usar uma versão específica do compilador, remova as referências a Microsoft.Net.Compilers. Caso contrário, certifique-se de que a versão do pacote referenciado também é 2.6 ou posterior.

Tente obter o caminho do log de erros, que é especificado na opção csc.exe /errorlog. A opção e o caminho aparecem no log da tarefa de compilação do Roslyn Analyzers. Eles podem se parecer com /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

A versão do compilador C# não é recente o suficiente

Para obter as versões mais recentes do compilador C#, vá para Microsoft.Net.Compilers. Para obter a versão instalada, execute csc.exe /version em um prompt de comando. Certifique-se de fazer referência a um pacote NuGet Microsoft.Net.Compilers versão 2.6 ou posterior.

Os logs MSBuild e VSBuild não foram encontrados

A tarefa de compilação do Roslyn Analyzers deve consultar o Azure DevOps para o log do MSBuild a partir da tarefa de compilação do MSBuild. Se a tarefa do analisador for executada imediatamente após a tarefa do MSBuild, o log ainda não estará disponível. Coloque outras tarefas entre a tarefa MSBuild e a tarefa Roslyn Analyzers. Exemplos de outras tarefas incluem BinSkim e Anti-Malware Scanner.

Próximos passos

Se precisar de assistência adicional, o Suporte de Análise de Código de Segurança da Microsoft está disponível de segunda a sexta-feira, das 9h00 às 17h00, horário padrão do Pacífico.

• Onboarding: Consulte nossa documentação de Onboarding

• Suporte: Envie um e-mail para nossa equipe em de Suporte de Análise de Código de Segurança da Microsoft