Decompiled Sources only show "throw null" for every .NET Framework class

Question

I have

installed Visual Studio Community 2019, version 16.3.3 (including "ASP.NET and Web development" and ".NET Core cross-platform development")
and have checked "Enable Navigation to decompiled Sources",
and created a new ASP.NET Core Web Application (.NET Core 3.0.0)

but when I then look at e.g. the decompiled source for any referenced class in the .NET framework e.g. System.Console or for Microsoft.AspNetCore.Builder (or almost any other type), all I can see for every method's body is throw null (I showed an extract below)

I have read this question (update: and the answer to the question it was a duplicate to), but there only one class had this problem (because it was added in an incremental update). For me, this problem applies to every class in the .NET framework. What am I doing wrong? Is this expected behaviour and I should use something like dotPeek? Can I use a symbols server instead of decompiled sources? (Forgive my ignorance, I'm really new to C#... and the .NET world)

region Assembly System.Console, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0\ref\netcoreapp3.0\System.Console.dll
// Decompiled with ICSharpCode.Decompiler 4.0.0.4521
#endregion

using System.IO;
using System.Text;
namespace System
{

// Summary:
// .... 
    public static ConsoleColor BackgroundColor
    {
        get
        {
            throw null;
        }
        set
        {
        }
    }

    //
    // Summary:
    //...
    public static int BufferHeight
    {
        get
        {
            throw null;
        }
        set
        {
        }
    }
    ...

[This answer](https://stackoverflow.com/a/9702071/463623) is probably what explaisn what you are seeing. What you are looking at is just a "Reference" assembly, that contains the metadata and type signatures. The actual implementation is somewhere else. — Euphoric, Oct 10 '19 at 10:48
Hm, I read this answer originally as well (it's linked as the answer to the question above), but there it says that this is the case because the class in question was added in an incremental update. For me, every class is like this. If I'm looking in the wrong location (the reference), how can I make Visual studio look into the correct one? Alternatively, Is it possible to use a symbols server instead of decompiled sources, like I do when I'm setting a debugging breakpoint? — z_eb, Oct 10 '19 at 11:22
So how to find the real assembly? And why not decompile that? — Wouter, May 02 '20 at 16:40
Actually look at https://github.com/dotnet/runtime implementations can be found there — Nick Kovalsky, Mar 09 '21 at 11:27
You need to find the folder where you installed your runtime. Eg. a path to the authentication dll for builder.Services.AddAuthentication is /usr/share/dotnet/shared/Microsoft.AspNet.Core.App/6.0.0/Microsoft.AspNetCore.Authentication.dll then open it with your decompiler (eg. ILSpy in vscode) directly — , Dec 06 '21 at 13:53

Decompiled Sources only show "throw null" for every .NET Framework class

0 Answers0