Vanliga frågor och svar | Blått

Anmärkning

Från och med den 31 december 2022 har tillägget Microsoft Security Code Analysis (MSCA) dragits tillbaka. MSCA ersätts av Microsoft Security DevOps Azure DevOps-tillägget. Följ anvisningarna i Konfigurera för att installera och konfigurera tillägget.

Allmänna frågor och svar

Kan jag installera tillägget på min Azure DevOps Server-instans (tidigare Visual Studio Team Foundation Server) i stället för på en Azure DevOps-instans?

Nej. Tillägget är inte tillgängligt för nedladdning och installation för Azure DevOps Server (tidigare Visual Studio Team Foundation Server).

Måste jag köra Microsoft Security Code Analysis med min version?

Kanske. Det beror på typen av analysverktyg. Källkoden kan vara det enda som krävs, eller så kan kompileringsutdata krävas.

CredScan (CredScan) analyserar till exempel filer i mappstrukturen för kodlagringsplatsen. På grund av den här analysen kan du köra bygguppgifterna CredScan och Publicera säkerhetsanalysloggar i en fristående version för att få resultat.

För andra verktyg som BinSkim som analyserar artefakter efter bygget krävs bygget först.

Kan jag bryta min version när resultat hittas?

Ja. Du kan introducera en byggpaus när något verktyg rapporterar ett problem eller problem i loggfilen. Lägg till byggaktiviteten Efter analys och markera kryssrutan för alla verktyg som du vill bryta bygget för.

I användargränssnittet för uppgiften Efter analys kan du välja att bryta bygget när något verktyg rapporterar antingen endast fel eller både fel och varningar.

Hur skiljer sig kommandoradsargumenten i Azure DevOps från argumenten i de fristående skrivbordsverktygen?

Vanligtvis är Azure DevOps-bygguppgifterna direkta omslutningar kring kommandoradsargumenten i säkerhetsverktygen. Du kan skicka som argument till en bygguppgift allt du normalt skickar till ett kommandoradsverktyg.

Märkbara skillnader:

• Verktyg körs från källmappen för agenten $(Build.SourcesDirectory) eller från %BUILD_SOURCESDIRECTORY%. Ett exempel är C:\agent_work\1\s.
• Sökvägarna i argumenten kan vara relativa till roten i källkatalogen som tidigare angavs. Sökvägar kan också vara absoluta. Du får absoluta sökvägar antingen med hjälp av Azure DevOps Build Variables eller genom att köra en lokal agent med kända distributionsplatser för lokala resurser.
• Verktyg tillhandahåller automatiskt en sökväg eller mapp för utdatafilen. Om du anger en utdataplats för en byggaktivitet ersätts den platsen med en sökväg till vår välkända plats för loggar på byggagenten
• Vissa andra kommandoradsargument ändras för vissa verktyg. Ett exempel är tillägg eller borttagning av alternativ som säkerställer att inget GUI startas.

Kan jag köra en bygguppgift som Autentiseringsskanner på flera lagringsplatser i en Azure DevOps Build?

Nej. Det går inte att köra de säkra utvecklingsverktygen på flera lagringsplatser i en enda pipeline.

Den angivna utdatafilen skapas inte, eller så hittar jag inte den utdatafil som jag har angett

Bygguppgifterna filtrerar vissa användarindata. För den här frågan uppdaterar de platsen för den genererade utdatafilen så att den är en gemensam plats i byggagenten. Mer information om den här platsen finns i följande frågor.

Var sparas utdatafilerna som genereras av verktygen?

Bygguppgifterna lägger automatiskt till utdatasökvägar till den här välkända platsen på byggagenten: $(Agent.BuildDirectory)_sdt\logs. Eftersom vi standardiserar på den här platsen har alla team som producerar eller använder kodanalysloggar åtkomst till utdata.

Kan jag köa ett bygge för att köra dessa uppgifter på en värdbaserad byggagent?

Ja. Alla uppgifter och verktyg i tillägget kan köras på en värdbaserad byggagent.

Anmärkning

Bygguppgiften Skanner mot skadlig kod kräver en byggagent med Windows Defender aktiverat. Värdbaserad Visual Studio 2017 och senare tillhandahålla en sådan agent. Byggaktiviteten körs inte på den värdbaserade Agenten i Visual Studio 2015.

Även om signaturer inte kan uppdateras på dessa agenter bör signaturer alltid vara mindre än tre timmar gamla.

Kan jag köra dessa bygguppgifter som en del av en versionspipeline i stället för en bygg-pipeline?

I de flesta fall, ja.

Azure DevOps stöder dock inte aktiviteter som körs i versionspipelines när dessa uppgifter publicerar artefakter. Den här bristen på stöd hindrar uppgiften Publicera säkerhetsanalysloggar från att köras i en versionspipeline. Uppgiften misslyckas i stället med ett beskrivande felmeddelande.

Varifrån laddar bygguppgifterna ned verktygen?

Bygguppgifter kan ladda ned verktygens NuGet-paket från Azure DevOps Package Management-feed. Build-uppgifter kan också använda Node Package Manager, som måste förinstalleras på byggagenten. Ett exempel på en sådan installation är kommandot npm install tslint.

Vilken effekt har installationen av tillägget på min Azure DevOps-organisation?

När de har installerats blir de säkerhetsversionsuppgifter som tillhandahålls av tillägget tillgängliga för alla användare i din organisation. När du skapar eller redigerar en Azure Pipeline är dessa uppgifter tillgängliga från samlingslistan build-task. Annars har det ingen effekt att installera tillägget i Din Azure DevOps-organisation. Installationen ändrar inga kontoinställningar, projektinställningar eller pipelines.

Ändrar installationen av tillägget mina befintliga Azure Pipelines?

Nej. Om du installerar tillägget blir säkerhetsbygguppgifterna tillgängliga för tillägg till dina pipelines. Du måste fortfarande lägga till eller uppdatera byggdefinitioner så att verktygen kan fungera med din byggprocess.

Uppgiftsspecifika vanliga frågor och svar

Frågor som är specifika för bygguppgifter visas i det här avsnittet.

Skanner för autentiseringsuppgifter

Vad är vanliga undertryckningsscenarier och exempel?

Här följer information om två av de vanligaste undertryckningsscenarierna.

Så här utelämnar du alla förekomster av en viss hemlighet inom den angivna sökvägen

Hash-nyckeln för hemligheten från CredScan-utdatafilen krävs enligt följande exempel.

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

Varning

Hash-nyckeln genereras av en del av matchande värde eller filinnehåll. Alla källkodsrevisioner kan ändra hash-nyckeln och inaktivera undertryckningsregeln.

Så här utelämnar du alla hemligheter i en angiven fil eller utelämnar själva hemlighetsfilen

Filuttrycket kan vara ett filnamn. Det kan också vara basnamndelen av en fullständig filsökväg eller ett filnamn. Jokertecken stöds inte.

Följande exempel visar hur du utelämnar filen <InputPath->\src\JS\lib\angular.js

Exempel på giltiga regler för undertryckning:

• <InputPath->\src\JS\lib\angular.js – undertrycker filen i den angivna sökvägen
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js – utelämnar alla filer med samma namn

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

Varning

Alla framtida hemligheter som läggs till i filen ignoreras också automatiskt.

Vilka är rekommenderade riktlinjer för att hantera hemligheter?

Följande resurser hjälper dig att hantera hemligheter på ett säkert sätt och få åtkomst till känslig information inifrån dina program:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• Azure AD Managed Service Identity (MSI)
• Hanterade identiteter för Azure-resurser
• hanterade identiteter i Azure App Service och Azure Functions
• AppAuthentication-bibliotek

Mer information finns i blogginlägget Hantera hemligheter på ett säkert sätt i molnet.

Kan jag skriva egna anpassade sökare?

Autentiseringsskannern förlitar sig på en uppsättning innehållssökare som ofta definieras i buildsearchers.xml-filen. Filen innehåller en matris med XML-serialiserade objekt som representerar ett ContentSearcher- objekt. Programmet distribueras med en uppsättning vältestade sökare. Men du kan även implementera dina egna anpassade sökare.

En innehållssökare definieras på följande sätt:

• Namn: Det beskrivande söknamnet som ska användas i utdatafilerna för autentiseringsläsaren. Vi rekommenderar att du använder namngivningskonventionen för kamelfall för söknamn.

• RuleId: Sökarens stabila ogenomskinliga ID:

  • En standardsökare för autentiseringsuppgifter tilldelas ett RuleId- värde som CSCAN0010, CSCAN0020 eller CSCAN0030. Den sista siffran är reserverad för potentiell sammanslagning eller delning av sökgrupper via reguljära uttryck (regex).
  • Värdet RuleId för en anpassad sökare ska ha ett eget namnområde. Exempel är CSCAN –<Namnområde>0010, CSCAN –<Namnområde>0020 och CSCAN –<Namnområde>0030.
  • Ett fullständigt kvalificerat söknamn är kombinationen av ett RuleId--värde och ett söknamn. Exempel är CSCAN0010. KeyStoreFiles och CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex av filnamnstillägg för att kontrollera mot sökaren.

• ContentSearchPatterns: En matris med strängar som innehåller regex-instruktioner som ska matchas. Om inga sökmönster har definierats returneras alla filer som matchar värdet ResourceMatchPattern.

• ContentSearchFilters: En matris med strängar som innehåller regex-instruktioner för att filtrera sökspecifika falska positiva identifieringar.

• MatchDetails: Ett beskrivande meddelande, åtgärdsinstruktioner eller båda som ska läggas till för varje matchning av sökaren.

• Rekommendation: Innehållet i förslagsfältet för en matchning med hjälp av PREfast-rapportformatet.

• Allvarlighetsgrad: Ett heltal som återspeglar allvarlighetsgraden för ett problem. Den högsta allvarlighetsgraden har värdet 1.

  

Roslyn Analyzeers

Vad är vanliga fel när du använder uppgiften Roslyn Analyzeers?

Projektet återställdes med fel Microsoft.NETCore.App version

Det fullständiga felmeddelandet:

"Fel: Projektet återställdes med Microsoft.NETCore.App version x.x.x, men med aktuella inställningar används version y.y.y.y i stället. Lös problemet genom att kontrollera att samma inställningar används för återställning och för efterföljande åtgärder, till exempel skapa eller publicera. Det här problemet kan vanligtvis inträffa om egenskapen RuntimeIdentifier anges under bygget eller publiceringen, men inte under återställningen."

Eftersom Roslyn Analyzeers-uppgifter körs som en del av kompileringen måste källträdet på byggdatorn vara i ett byggbart tillstånd.

Ett steg mellan stegen för huvudversionen och Roslyn Analyzeers kan ha försatt källträdet i ett tillstånd som förhindrar skapande. Det här extra steget är förmodligen dotnet.exe publicera. Prova att duplicera steget som gör en NuGet-återställning precis före Roslyn Analyzeers-steget. Det här duplicerade steget kan försätta källträdet i ett byggbart tillstånd igen.

csc.exe kan inte skapa en analysinstans

Det fullständiga felmeddelandet:

"'csc.exe" avslutades med felkod 1 – En instans av analysatorn AAAA- kan inte skapas från C:\BBBB.dll: Det gick inte att läsa in filen eller sammansättningen Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' eller något av dess beroenden. Det går inte att hitta den angivna filen."

Se till att kompilatorn stöder Roslyn Analyzeers. Om du kör kommandot csc.exe /version bör du rapportera ett versionsvärde på 2,6 eller senare.

Ibland kan en .csproj-fil åsidosätta build-datorns Visual Studio-installation genom att referera till ett paket från Microsoft.Net.Compilers. Om du inte tänker använda en specifik version av kompilatorn tar du bort referenser till Microsoft.Net.Compilers. Annars kontrollerar du att versionen av det refererade paketet också är 2.6 eller senare.

Försök att hämta felloggsökvägen, som anges i alternativet csc.exe/errorlog. Alternativet och sökvägen visas i loggen för Roslyn Analyzeers-bygguppgiften. De kan se ut ungefär som /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

C#-kompilatorversionen är inte tillräckligt ny

Om du vill hämta de senaste versionerna av C#-kompilatorn går du till Microsoft.Net.Compilers. Hämta den installerade versionen genom att köra csc.exe /version i en kommandotolk. Kontrollera att du refererar till ett Microsoft.Net.Compilers NuGet-paket som är version 2.6 eller senare.

MSBuild- och VSBuild-loggar hittas inte

Roslyn Analyzeers-bygguppgiften måste fråga Azure DevOps efter MSBuild-loggen från MSBuild-byggaktiviteten. Om analysaktiviteten körs omedelbart efter MSBuild-aktiviteten är loggen ännu inte tillgänglig. Placera andra uppgifter mellan MSBuild-aktiviteten och Roslyn Analyzeers-aktiviteten. Exempel på andra uppgifter är BinSkim och Anti-Malware Scanner.

Nästa steg

Om du behöver ytterligare hjälp är Microsoft Security Code Analysis Support tillgängligt måndag till fredag från 09:00 till 17:00 Pacific Standard Time.

• Onboarding: Se vår Onboarding-dokumentation

• Support: Skicka e-post till vårt team på Microsoft Security Code Analysis Support

Anmärkning

Från och med den 31 december 2022 har tillägget Microsoft Security Code Analysis (MSCA) dragits tillbaka. MSCA ersätts av Microsoft Security DevOps Azure DevOps-tillägget. Följ anvisningarna i Konfigurera för att installera och konfigurera tillägget.

Nej. Tillägget är inte tillgängligt för nedladdning och installation för Azure DevOps Server (tidigare Visual Studio Team Foundation Server).

Kanske. Det beror på typen av analysverktyg. Källkoden kan vara det enda som krävs, eller så kan kompileringsutdata krävas.

CredScan (CredScan) analyserar till exempel filer i mappstrukturen för kodlagringsplatsen. På grund av den här analysen kan du köra bygguppgifterna CredScan och Publicera säkerhetsanalysloggar i en fristående version för att få resultat.

För andra verktyg som BinSkim som analyserar artefakter efter bygget krävs bygget först.

Ja. Du kan introducera en byggpaus när något verktyg rapporterar ett problem eller problem i loggfilen. Lägg till byggaktiviteten Efter analys och markera kryssrutan för alla verktyg som du vill bryta bygget för.

I användargränssnittet för uppgiften Efter analys kan du välja att bryta bygget när något verktyg rapporterar antingen endast fel eller både fel och varningar.

Vanligtvis är Azure DevOps-bygguppgifterna direkta omslutningar kring kommandoradsargumenten i säkerhetsverktygen. Du kan skicka som argument till en bygguppgift allt du normalt skickar till ett kommandoradsverktyg.

Märkbara skillnader:

• Verktyg körs från källmappen för agenten $(Build.SourcesDirectory) eller från %BUILD_SOURCESDIRECTORY%. Ett exempel är C:\agent_work\1\s.
• Sökvägarna i argumenten kan vara relativa till roten i källkatalogen som tidigare angavs. Sökvägar kan också vara absoluta. Du får absoluta sökvägar antingen med hjälp av Azure DevOps Build Variables eller genom att köra en lokal agent med kända distributionsplatser för lokala resurser.
• Verktyg tillhandahåller automatiskt en sökväg eller mapp för utdatafilen. Om du anger en utdataplats för en byggaktivitet ersätts den platsen med en sökväg till vår välkända plats för loggar på byggagenten
• Vissa andra kommandoradsargument ändras för vissa verktyg. Ett exempel är tillägg eller borttagning av alternativ som säkerställer att inget GUI startas.

Nej. Det går inte att köra de säkra utvecklingsverktygen på flera lagringsplatser i en enda pipeline.

Bygguppgifterna filtrerar vissa användarindata. För den här frågan uppdaterar de platsen för den genererade utdatafilen så att den är en gemensam plats i byggagenten. Mer information om den här platsen finns i följande frågor.

Bygguppgifterna lägger automatiskt till utdatasökvägar till den här välkända platsen på byggagenten: $(Agent.BuildDirectory)_sdt\logs. Eftersom vi standardiserar på den här platsen har alla team som producerar eller använder kodanalysloggar åtkomst till utdata.

Ja. Alla uppgifter och verktyg i tillägget kan köras på en värdbaserad byggagent.

Anmärkning

Bygguppgiften Skanner mot skadlig kod kräver en byggagent med Windows Defender aktiverat. Värdbaserad Visual Studio 2017 och senare tillhandahålla en sådan agent. Byggaktiviteten körs inte på den värdbaserade Agenten i Visual Studio 2015.

Även om signaturer inte kan uppdateras på dessa agenter bör signaturer alltid vara mindre än tre timmar gamla.

I de flesta fall, ja.

Azure DevOps stöder dock inte aktiviteter som körs i versionspipelines när dessa uppgifter publicerar artefakter. Den här bristen på stöd hindrar uppgiften Publicera säkerhetsanalysloggar från att köras i en versionspipeline. Uppgiften misslyckas i stället med ett beskrivande felmeddelande.

Bygguppgifter kan ladda ned verktygens NuGet-paket från Azure DevOps Package Management-feed. Build-uppgifter kan också använda Node Package Manager, som måste förinstalleras på byggagenten. Ett exempel på en sådan installation är kommandot npm install tslint.

När de har installerats blir de säkerhetsversionsuppgifter som tillhandahålls av tillägget tillgängliga för alla användare i din organisation. När du skapar eller redigerar en Azure Pipeline är dessa uppgifter tillgängliga från samlingslistan build-task. Annars har det ingen effekt att installera tillägget i Din Azure DevOps-organisation. Installationen ändrar inga kontoinställningar, projektinställningar eller pipelines.

Nej. Om du installerar tillägget blir säkerhetsbygguppgifterna tillgängliga för tillägg till dina pipelines. Du måste fortfarande lägga till eller uppdatera byggdefinitioner så att verktygen kan fungera med din byggprocess.

Uppgiftsspecifika vanliga frågor och svar

Frågor som är specifika för bygguppgifter visas i det här avsnittet.

Här följer information om två av de vanligaste undertryckningsscenarierna.

Så här utelämnar du alla förekomster av en viss hemlighet inom den angivna sökvägen

Hash-nyckeln för hemligheten från CredScan-utdatafilen krävs enligt följande exempel.

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

Varning

Hash-nyckeln genereras av en del av matchande värde eller filinnehåll. Alla källkodsrevisioner kan ändra hash-nyckeln och inaktivera undertryckningsregeln.

Så här utelämnar du alla hemligheter i en angiven fil eller utelämnar själva hemlighetsfilen

Filuttrycket kan vara ett filnamn. Det kan också vara basnamndelen av en fullständig filsökväg eller ett filnamn. Jokertecken stöds inte.

Följande exempel visar hur du utelämnar filen <InputPath->\src\JS\lib\angular.js

Exempel på giltiga regler för undertryckning:

• <InputPath->\src\JS\lib\angular.js – undertrycker filen i den angivna sökvägen
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js – utelämnar alla filer med samma namn

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

Varning

Alla framtida hemligheter som läggs till i filen ignoreras också automatiskt.

Följande resurser hjälper dig att hantera hemligheter på ett säkert sätt och få åtkomst till känslig information inifrån dina program:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• Azure AD Managed Service Identity (MSI)
• Hanterade identiteter för Azure-resurser
• hanterade identiteter i Azure App Service och Azure Functions
• AppAuthentication-bibliotek

Mer information finns i blogginlägget Hantera hemligheter på ett säkert sätt i molnet.

Autentiseringsskannern förlitar sig på en uppsättning innehållssökare som ofta definieras i buildsearchers.xml-filen. Filen innehåller en matris med XML-serialiserade objekt som representerar ett ContentSearcher- objekt. Programmet distribueras med en uppsättning vältestade sökare. Men du kan även implementera dina egna anpassade sökare.

En innehållssökare definieras på följande sätt:

• Namn: Det beskrivande söknamnet som ska användas i utdatafilerna för autentiseringsläsaren. Vi rekommenderar att du använder namngivningskonventionen för kamelfall för söknamn.

• RuleId: Sökarens stabila ogenomskinliga ID:

  • En standardsökare för autentiseringsuppgifter tilldelas ett RuleId- värde som CSCAN0010, CSCAN0020 eller CSCAN0030. Den sista siffran är reserverad för potentiell sammanslagning eller delning av sökgrupper via reguljära uttryck (regex).
  • Värdet RuleId för en anpassad sökare ska ha ett eget namnområde. Exempel är CSCAN –<Namnområde>0010, CSCAN –<Namnområde>0020 och CSCAN –<Namnområde>0030.
  • Ett fullständigt kvalificerat söknamn är kombinationen av ett RuleId--värde och ett söknamn. Exempel är CSCAN0010. KeyStoreFiles och CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex av filnamnstillägg för att kontrollera mot sökaren.

• ContentSearchPatterns: En matris med strängar som innehåller regex-instruktioner som ska matchas. Om inga sökmönster har definierats returneras alla filer som matchar värdet ResourceMatchPattern.

• ContentSearchFilters: En matris med strängar som innehåller regex-instruktioner för att filtrera sökspecifika falska positiva identifieringar.

• MatchDetails: Ett beskrivande meddelande, åtgärdsinstruktioner eller båda som ska läggas till för varje matchning av sökaren.

• Rekommendation: Innehållet i förslagsfältet för en matchning med hjälp av PREfast-rapportformatet.

• Allvarlighetsgrad: Ett heltal som återspeglar allvarlighetsgraden för ett problem. Den högsta allvarlighetsgraden har värdet 1.

  

Projektet återställdes med fel Microsoft.NETCore.App version

Det fullständiga felmeddelandet:

"Fel: Projektet återställdes med Microsoft.NETCore.App version x.x.x, men med aktuella inställningar används version y.y.y.y i stället. Lös problemet genom att kontrollera att samma inställningar används för återställning och för efterföljande åtgärder, till exempel skapa eller publicera. Det här problemet kan vanligtvis inträffa om egenskapen RuntimeIdentifier anges under bygget eller publiceringen, men inte under återställningen."

Eftersom Roslyn Analyzeers-uppgifter körs som en del av kompileringen måste källträdet på byggdatorn vara i ett byggbart tillstånd.

Ett steg mellan stegen för huvudversionen och Roslyn Analyzeers kan ha försatt källträdet i ett tillstånd som förhindrar skapande. Det här extra steget är förmodligen dotnet.exe publicera. Prova att duplicera steget som gör en NuGet-återställning precis före Roslyn Analyzeers-steget. Det här duplicerade steget kan försätta källträdet i ett byggbart tillstånd igen.

csc.exe kan inte skapa en analysinstans

Det fullständiga felmeddelandet:

"'csc.exe" avslutades med felkod 1 – En instans av analysatorn AAAA- kan inte skapas från C:\BBBB.dll: Det gick inte att läsa in filen eller sammansättningen Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' eller något av dess beroenden. Det går inte att hitta den angivna filen."

Se till att kompilatorn stöder Roslyn Analyzeers. Om du kör kommandot csc.exe /version bör du rapportera ett versionsvärde på 2,6 eller senare.

Ibland kan en .csproj-fil åsidosätta build-datorns Visual Studio-installation genom att referera till ett paket från Microsoft.Net.Compilers. Om du inte tänker använda en specifik version av kompilatorn tar du bort referenser till Microsoft.Net.Compilers. Annars kontrollerar du att versionen av det refererade paketet också är 2.6 eller senare.

Försök att hämta felloggsökvägen, som anges i alternativet csc.exe/errorlog. Alternativet och sökvägen visas i loggen för Roslyn Analyzeers-bygguppgiften. De kan se ut ungefär som /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

C#-kompilatorversionen är inte tillräckligt ny

Om du vill hämta de senaste versionerna av C#-kompilatorn går du till Microsoft.Net.Compilers. Hämta den installerade versionen genom att köra csc.exe /version i en kommandotolk. Kontrollera att du refererar till ett Microsoft.Net.Compilers NuGet-paket som är version 2.6 eller senare.

MSBuild- och VSBuild-loggar hittas inte

Roslyn Analyzeers-bygguppgiften måste fråga Azure DevOps efter MSBuild-loggen från MSBuild-byggaktiviteten. Om analysaktiviteten körs omedelbart efter MSBuild-aktiviteten är loggen ännu inte tillgänglig. Placera andra uppgifter mellan MSBuild-aktiviteten och Roslyn Analyzeers-aktiviteten. Exempel på andra uppgifter är BinSkim och Anti-Malware Scanner.

Nästa steg

Om du behöver ytterligare hjälp är Microsoft Security Code Analysis Support tillgängligt måndag till fredag från 09:00 till 17:00 Pacific Standard Time.

• Onboarding: Se vår Onboarding-dokumentation

• Support: Skicka e-post till vårt team på Microsoft Security Code Analysis Support