[Portable PDB] Source control information and interop with symbol servers

[tmat]

Right now I'm thinking about adding a compiler parameter that specifies a file with additional custom debug information data. Something like /customDebugInfo:{GUID}=. The compiler would add a row to CustomDebugInformation table (with Parent = Assembly) and embed the content of the specified file on the #Blob heap of the portable PDB.

In addition, we are also thinking about the ability to mark input source files as "debuggable tool generated file" (i.e. not checked into any source control, but still something that the user would want to step thru). The content of such files would be zip compressed and stored in the Portable PDB as well.

Each kind of source server (GIT, TFS, Subver, etc) has their own format. A source server specific tool would need to run as a task before compilation and create the CDI file passed to /customDebugInfo.

Since the SHA1 hashes of all source files are already included in the Document table the only information needed to find the sources in GIT repo would be the URL of the repo. So the generated CDI would just contain that.

[0x53A]

@tmat Please also consider adding an option to the compiler to embed ALL sources in the pdb as suggested by @erik-kallen here:
#3891

This would be especially useful for small apps, which might (heavens forbid!) not even be under source control. Just saving the .exe and .pdb would then allow source-debugging.

It might also be useful for nugget libraries. Instead of having to configure 1) nuget, 2) symbol server and 3) source server, you could skip 3. (Some nuget packages also contain the pdb, so these could be self-contained, but that practice might not be optimal, as it increases the size of the package)

Lastly, it might be useful for offline scenarios, where you have the pdb but no access to the internet to download the sources.

[Pilchie]

Since the SHA1 hashes of all source files are already included in the Document table the only information needed to find the sources in GIT repo would be the URL of the repo. So the generated CDI would just contain that.

Note that we might not want to rely on this. Isn't the SHA in the PDB the sha based on a specfic string encoding that the compiler chose to interpret the file in, whereas Git's will be a SHA of the raw file bytes?

[ctaggart]

@Pilchie They are both checksums of the raw file bytes. Git uses SHA1, but prefixes the stream.
https://github.com/ctaggart/SourceLink/blob/master/Git/GitRepo.fs#L27-L32

The pdb files store the MD5, SHA1, or SHA256 checksums.
https://github.com/ctaggart/SourceLink/blob/master/SourceLink/Crypto.fs#L36-L38

[tmat]

We decided on a different design. The work has moved to https://github.com/dotnet/symstore.

[ctaggart]

Thank for the link @tmat. I'll go though the specs soon:
https://github.com/dotnet/symstore/tree/master/docs/specs