How Microsoft Hides C# Internal Classes from a DLL's Metadata?

It all started when I wanted to analyze the code around CVE-2017-8759. I knew that the fix for the CVE was in a class named WsdlParser.cs inside System.Runtime.Remoting.dll which is part of the .Net Framework. You probably have this dll on your computer at a location similar to:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7\System.Runtime.Remoting.dll

I used ilspycmd to re-assemble the code back to C#, and noticed that the WsdlParser.cs was missing in the output directory:

I later used CFF Explorer and saw that this type is indeed missing in the metadata in TypeDefs:

However, I know for a fact that this class is there:

• It's in Microsoft's documentation: https://referencesource.microsoft.com/System.Runtime.Remoting/metadata/wsdlparser.cs.html

• When using reflection and LoadAssembly() I was able to find the class:

      Assembly assembly = Assembly.LoadFile(@"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Runtime.Remoting.dll");
  
      foreach (var type in assembly.GetTypes())
      {
          if (!type.FullName.EndsWith("WsdlParser"))
          {
              continue;
          }
  
          Console.WriteLine("Great Success");
      }
  

I noticed that this behavior is consistent to all internal classes in this dll, but I don't understand how it makes sense. My guess is there might be a post-build procedure to remove data of internal types, but if so, how was I able to find the class by loading the assembly? I thought that the CIL loads types using the TypeDef metadata, but is there an additional space where this data is stored?

In order to understand it better, I created a C# test project with an internal class, and inspected the metadata using CFF Explorer. The internal class was there, as it should be, in debug and in release builds.

So what is this voodoo?

Thanks guys.