Here's how the managed symbol API fits into the overall symbol-store / PDB picture, courtesy of Steve Steiner and Curtis Man.

There's a basic uniform low level storage for both managed and native symbols. The low-level API is private, and then there are public higher level APIs that build on top of that.
Here's everything in table form:

public API dll What it does: Dependencies Used by:
low-level API, non-public MsPdb80 Read + write general symbols   used by VS native-debugger
DIA interaces, a COM-classic (unmanaged) API. MsDia80 read-only general symbols. static link to mspdb80 VS managed-debugger, Windbg
DbgHelp, C-style (unmanaged) API. Dbghelp.dll read native symbols uses DIA api, static link msdia, mspdb public tools to manipulate native symbols.
CorSym.idl, a COM-classic (unmanaged) API DiaSymReader.dll reader + writer for managed symbols reader statically links msdia80.
writer statically links mspdb80.		 Managed-tools including: CLR, StackTrace class, .NET compilers, MDbg, ILasm/ILdasm, Reflection-emit

System.Diagnostics.SymbolStore interfaces in mscorlib.
managed wrappers for CorSym.idl

 Get from mscorlib, lives in ISymWrapper.dll wrapper for reader for managed symbols. dynamically links diasymreader.dll Similar users as CorSym.idl. 
The ISymWrapper is used by Reflection-Emit to let users emit sequence points in their newly generated code.
These are MC++ wrappers and are mostly incomplete, especially on the writer.
FWIW, we would like to deprecate these .
MDbg wrappers for System.Diagnostics.SymbolStore 
interfaces in managed wrappers for CorSym.idl		 MDbg wrappers. See MDbg source. wrapper for reader for managed symbols. CoCreates
diasymreader.dll

Similar same users as CorSym.idl.  MDbg wrappers are used by MDbg. These are COM-interop based wrappers. I personally would encourage folks to use these wrappers instead of the ISymWrapper ones for their own private tools. They're more complete than ISymWrapper.dll. Since Mdbg source ships as a public sample, the source is also available.