I recently stumbled upon a new .NET tool that I find very useful. One of the pain points of developing a complicated library is that when users face a problem, they often provide inadequate information about the circumstances. This is not always their fault, as it is awkward to try to debug an already compiled library but this will hopefully eliminate that and give them the power to analyze even inside of a compiled library.
A little background here: When you compile a .NET library or executable locally, traditionally the compiler has embedded an absolute path to the corresponding source files inside of the PDB symbols file that goes along with the binary. This means that you can step into the source easily, but if you move it to another computer suddenly the debugger must ask you “WHERE IS THE FILE?”
At some point Microsoft added a concept called a source server, which would store the source for a given version of the binary file. However, this required two extra steps for the user: Enabling source server support and adding a custom URL to their symbol server list. After that, a project called GitLink came about that would embed certain metadata into a PDB file that would instruct the debugger to pull source files directly from GitHub (or Bitbucket, etc) when they were needed. This was forked to PdbGit to add some more features that were (at least initially) refused by GitLink.
Recently, Microsoft has improved upon the source server model with a concept called source linking. This will apply to the new PDB format, which is a big improvement on the previous iteration. It allows information about where the source files were retrieved to be embedded into the PDB, and can even embed the source files themselves if the former is not possible. However, once again, this requires some PDB editing. Since the portable PDB format is documented and there is support for reading them built into the .NET Framework Libraries this is a pretty easy task and someone was up to the job!
SourceLink is a tool that will automatically embed this information into your PDB files at build time via an include MSBuild task. It works pretty well, except for one shortcoming that I filed a PR for. It is seamless and the end result is that the user simply has to turn on the source link support option in Visual Studio and after that they will be able to step into the source of the compiled library to do some additional debugging, and hopefully provide me the exact location of where things are going wrong.