Proposal: Add compiler switch to embed PDB inside the assembly

[mjsabby]

Roslyn generates PDBs and store them as an external artifact (a .pdb file).

The request is to add a switch where the PDB can be embedded either as a well-known resource stream inside the assembly or inside the metadata tables. This coupled with #12353 (which is a feature to embed source files inside PDBs) can make very interesting and sophisticated analysis tools that can analyze MSIL and/or source with just the assembly if it were compiled with this switch.

Note: This is only a deployment optimization, in that all the information is already available via an external PDB and non-embedded sources, but for some scenarios where assembly size may not be a concern this can ease the deployment quite a bit.

Motivation: Imagine you're a performance analysis tool and you collect performance telemetry about a running application and this application was not built with the compiler flags that embed the pdb (and sources). In this case you'd have to find the PDB via a convention or prompt the user for a location. After the PDB is loaded, you'd need to find the source file by convention or prompting the user. However, if the assembly is built with these compiler flags and your tool is aware and able to detect this. You could with certainty open the embedded PDB, and the embedded sources and provide a seamless user experience.

Implementation Details: There are at least two ways to embed the pdb information inside the assembly:

1. Add the PDB to the metadata tables -- there is a concern that CoreCLR may not be able to load this without changes. If that is true, I'd like to take the second approach.
2. Add the PDB an embedded resource -- this solution is going to work without any problems, and in fact you can imagine this can be done without any changes to Roslyn even today.

Debugger and other tools support: While not an immediate goal of this feature, it is important to remember that the PDB is usually read by the debugger which means it would need an update to understand this new situation of an embedded PDB. I'd like to make this proposal independent of debugger support because usually people update their compilers relatively slowly so not having this in Roslyn 2.0 and waiting for alignment on debugger support will delay this even further.

The official CoreCLR debugger not supporting this shouldn't be a problem for tools people may want to write that takes advantage of this feature.

[mjsabby]

@tmat @noahfalk @nguerrera @jaredpar

[noahfalk]

Looks fine to me, assuming we go with implementation option #2 (unless someone proves me wrong and demonstrates that coreclr/desktop runtimes can load the IL images with extra tables)

[mjsabby]

Alright, I've concluded the runtime fails to load assemblies with option 1. So has to be an embedded resource. Challenge now is to come up with a unique name that is not a guid :)

[noahfalk]

I think Tomas was looking into this. Chat with him - last I heard he was looking into embedding it in the txt section and using the debug directory to point to it.

[noahfalk]

@tmat

[tmat]

Yes, I'm already working on it.

[tmat]

Roslyn and Core CLR now support Embedded Portable PDBs. The debugger work is in progress.