Mac
March 26, 2017, 9:55pm
1
So now that embedding pdb’s and sources is supported in roslyn and VS2017 are there objections/blockers to updating servicestack projects or compiling with the switch?
opened 12:42AM - 08 Jul 16 UTC
closed 08:43PM - 15 Aug 16 UTC
Interactive-Debugging
Feature Request
Area-Interactive
Resolution-Fixed
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.
As far as I can tell it is backwards compatible with older IDE’s and supported portable, core etc. It negates the need for separate symbol source servers in VS2017 so simpler debugging experience (but probably not for older IDE debuggers that would afaik revert to loading from symbol sources)
The packages would be slightly larger but smaller than existing dll + pdb. Haven’t seen anything to indicate it affects performance.
1 Like
mythz
March 26, 2017, 10:01pm
2
Yeah this looks like something we should consider after next release when we upgrade all projects and CI to VS2017.
1 Like