Dela via

Generera källkod från .NET-sammansättningar vid felsökning

  • Artikel

När du felsöker ett .NET-program kanske du vill visa källkod som du inte har. Till exempel om du bryter mot ett undantag eller använder anropsstacken för att navigera till en källplats.

Notis

  • Källkodsgenerering (dekompilering) är endast tillgängligt för .NET-program och baseras på projektet ILSpy med öppen källkod.
  • Dekompilering är endast tillgängligt i Visual Studio 2019 16.5 och senare.
  • Om du använder attributet SuppressIldasmAttribute på en sammansättning eller modul hindras Visual Studio från att försöka dekompilera. Även om attributet är föråldrat i .NET 6 och senare, respekterar Visual Studio attributet.

Generera källkod

När du felsöker och ingen källkod är tillgänglig visar Visual Studio dokumentet Källan kunde inte hittas eller, om du inte har symboler för samlingen, dokumentet Inga symboler lästes in. Båda dokumenten har ett dekompilera källkod alternativ som genererar C#-kod för den aktuella platsen. Den genererade C#-koden kan sedan användas precis som andra källkoder. Du kan visa koden, inspektera variabler, ange brytpunkter och så vidare.

Inga symboler har laddats in

Följande bild visar meddelandet Inga symboler läses in.

Skärmbild av dokument utan inladdade symboler

Källan hittades inte

Följande bild visar meddelandet Källan hittades inte.

Skärmbild av källan som inte hittades

Kod för automatisk kompilering

Från och med Visual Studio 2022 version 17.7 har Visual Studio-felsökaren stöd för automatisk komplettering av extern .NET-kod. Du kan automatiskt dekompilera när du kliver in i extern kod eller när du använder fönstret Samtalsstack.

Om du stiger in i kod som har implementerats externt, dekompilerar felsökaren automatiskt den och visar den aktuella exekveringspunkten. Om du vill gå in i extern kod inaktiverar du Just My Code.

Du kan dekompilera från fönstret anropsstacken utan att behöva inaktivera Just My Code.

För att avkompilera automatiskt från fönstret Anropsstack:

  1. När du felsöker med fönstret Samtalsstack öppet väljer du Visa extern kod.

  2. I fönstret Samtalsstack, dubbelklicka på valfri stackram. Felsökningsprogrammet dekompilerar koden och navigerar sedan direkt till den aktuella exekveringspunkten.

    Skärmbild av Anropsstackfönstret som visar extern kod.

    All dekompilerad kod visas också under noden Externa källor i Solution Explorer, vilket gör det enkelt att bläddra igenom de externa filerna om det behövs.

    Skärmbild av noden Externa källor som visar dekompilerade sammansättningar.

    Du kan felsöka den dekompilerade koden och ange brytpunkter.

Om du vill inaktivera automatisk dekompilering av extern kod går du till Verktyg > Alternativ > Felsökning > Allmänt och avmarkerar Kompilera automatiskt till källan vid behov (endast hanterad).

Generera och bädda in källor för en sammansättning

Förutom att generera källkod för en specifik plats kan du generera all källkod för en viss .NET-sammansättning. Om du vill utföra den här uppgiften går du till fönstret Moduler och från snabbmenyn för en .NET-sammansättning och väljer sedan kommandot Dekompilera källa till symbolfil. Visual Studio genererar en symbolfil för sammansättningen och bäddar sedan in källan i symbolfilen. I ett senare steg kan du extrahera den inbäddade källkoden.

Skärmbild av sammanställningens snabbmeny i modulfönstret med kommandot dekompilera källkod.

Extrahera och visa den inbäddade källkoden

Du kan extrahera källfiler som är inbäddade i en symbolfil med hjälp av kommandot Extrahera källkod i snabbmenyn i Modules-fönstret.

Skärmbild av snabbmenyn för sammansättning i modulfönstret med kommandot extrahera källor.

De extraherade källfilerna läggs till i lösningen som diverse filer. Funktionen för övriga filer är inaktiverad som standard i Visual Studio. Du kan aktivera den här funktionen från kryssrutan Tools>Options>Environment>Documents>Show Diverse filer i Solution Explorer. Om den här funktionen inte är aktiverad kan du inte öppna den extraherade källkoden.

Skärmbild av alternativsidan för verktyg med alternativet övriga filer aktiverat.

Extraherade källfiler visas i de olika filerna i Solution Explorer.

Skärmbild av Solution Explorer med diverse filer.

För .NET-bibliotek eller för NuGet-paket som är aktiverade för SourceLink kan du även gå in i källkod, ange brytpunkter och använda alla funktioner i felsökningsprogrammet. Mer information finns i Aktivera felsökning och diagnostik med Source Link och Förbättra produktiviteten vid felsökning med SourceLink.

Kända begränsningar

Kräver avbrottsläge

Det går bara att generera källkod med dekompilering när felsökningsprogrammet är i avbrottsläge och programmet har pausats. Visual Studio går till exempel in i brytläge när det träffar en brytpunkt eller ett undantag. Du kan enkelt utlösa Visual Studio för att bryta koden nästa gång den körs med kommandot Break All (Break all icon).

Begränsningar för dekompilering

Att generera källkod från mellanliggande format (IL) som används i .NET-sammansättningar har vissa inneboende begränsningar. Därför ser den genererade källkoden inte ut som den ursprungliga källkoden. De flesta skillnaderna finns på platser där informationen i den ursprungliga källkoden inte behövs vid körning. Till exempel behövs inte information som blanksteg, kommentarer och namnen på lokala variabler under körning. Vi rekommenderar att du använder den genererade källan för att förstå hur programmet körs och inte som en ersättning för den ursprungliga källkoden.

Felsöka optimerade eller versionssammansättningar

När du felsöker kod som dekompilerats från en sammansättning som kompilerats med hjälp av kompilatoroptimeringar kan du stöta på följande problem:

  • Brytpunkter kan inte alltid kopplas till den matchande källplatsen.
  • Stegning kanske inte alltid leder till rätt plats.
  • Lokala variabler kanske inte har korrekta namn.
  • Vissa variabler kanske inte är tillgängliga för utvärdering.

Mer information finns i GitHub-problemet: ICSharpCode.Decompiler-integrering i VS Debugger.

Tillförlitlighet för dekompilering

En relativt liten andel av dekompileringsförsöken kan leda till fel. Det här beteendet beror på ett null-referensfel för sekvenspunkten i ILSpy. Vi har åtgärdat felet genom att fånga upp dessa problem och på ett smidigt sätt misslyckas med dekompileringsförsöket.

Mer information finns i GitHub-problemet: ICSharpCode.Decompiler-integrering i VS Debugger.

Begränsningar med asynkron kod

Resultatet från dekompilering av moduler med asynkrona/väntande kodmönster kan vara ofullständiga eller misslyckas helt. ILSpy-implementeringen av async/await- och yield state-machines implementeras bara delvis.

Mer information finns i GitHub-problemet: PDB Generator Status.

Bara min kod

Inställningen Just My Code (JMC) gör att Visual Studio kan steppa över system-, ramverks-, biblioteks- och andra anrop som inte är användardefinierade. Under en felsökningssession visar fönstret Moduler vilka kodmoduler felsökaren behandlar som Min kod (användarkod).

Dekompilering av optimerade moduler eller versionsmoduler genererar icke-användarkod. Om felsökningsprogrammet stannar i din dekompilerade icke-användarkod, till exempel, visas fönstret Ingen källa. Om du vill inaktivera Just My Code går du till Tools>Options (eller Debug>Options) >Debugging>Generaloch avmarkerar sedan Enable Just My Code.

Extraherade källor

Källkoden som extraheras från en sammansättning har följande begränsningar:

  • Namnet och platsen för de genererade filerna kan inte konfigureras.
  • Filerna är tillfälliga och tas bort av Visual Studio.
  • Filerna placeras i en enda mapp och alla mapphierarkier som de ursprungliga källorna hade används inte.
  • Filnamnet för varje fil innehåller en checksum-hash för filen.

Genererad kod är endast C#

Dekompilering genererar endast källkodsfiler i C#. Det finns inget alternativ för att generera filer på något annat språk.