Ship with SourceLink

[jnm2]

Would you consider providing PDBs with SourceLink information? This will make it easy for anyone to drop into Castle.Windsor code any time they want to understand what's going on, and users may return the courtesy by taking some initiative in diagnosing bugs they observe. Creating a repro is much easier when you aren't dealing with a black box!

It's easier than it used to be because the csproj SDK now supports it. The recommended route is https://github.com/dotnet/sourcelink#sourcelink-preview.

(Just ran into 'Handler not found' exceptions inside DefaultDependencyResolver and wanted to investigate.)

[stakx]

I'm in principle a big fan of SourceLink, but I'd like to chime in here with a couple of potential issues that I've encountered in the past, so that we can make an informed decision:

• If you ship symbols (PDB files) in your main NuGet package, it'll become much larger unless you use the new portable PDB format. Using "classic" Windows PDBs can cause package bloat, especially when you target several platforms. Given today's network bandwidths and NuGet's offline package cache, this usually isn't a problem, but package sizes in excess of 1 MB are a real possibility.

• If you decide to use portable PDBs to prevent bloat (see point above), be aware that there are still tools that do not understand portable PDBs (e.g. Mono.Cecil-based tools like ILSpy, or older releases of VSTS / TFS; see e.g. track portable pdb woes ctaggart/SourceLink#258). Packaging PDBs within the main NuGet package can become an obstacle for people using such tools, forcing them to delete the problematic PDB files to get their tools working again.

• Some people are not well-informed about VS debugger settings like "Just My Code". They might become annoyed by VS stepping into third-party code, not realising that they could just enable "Just My Code" to avoid this.

• "Just My Code" is a very coarse-grained mechanism. It enables VS to step into all third-party code, or none at all. You cannot enable or disable the setting for specific third-party packages.

• While SourceLink allows you to step into a library's code, many debugger features will not work very well due to the libraries usually being compiled with optimizations enabled a.k.a. Release configuration. You'll notice the debugger hopping through source in unexpected order, you won't be able to inspect some local variables, etc. This somewhat limits the usefulness of SourceLink.

• ctaggart's original SourceLink tools are stable, while the newer dotnet/sourcelink tooling is still in pre-release. The official recommendation is for the newer pre-release tools, which brings up the question of whether SourceLink is really ready for prime time yet.

Due to the above potential problems, it might be good to also consider more traditional alternatives, like publishing separate symbol packages (which would enable users to choose whether they want the PDBs or not).

All of that being said, SourceLink-ing is the modern thing to do and it works well for many people.

[jnm2]

Some measurements I did for NUnit:

• Publishing symbols with releases nunit/nunit#2421 (comment)

• Publishing symbols with releases nunit/nunit3-vs-adapter#461 (comment)

[stakx]

An update regarding my above post: It has since become possible to ship SourceLink-ed portable PDB files in a separate NuGet symbols package (.snupkg), and with today's toolchain & updates to VS, it's fairly easy to produce, publish, and consume these. (I've recently done that for Moq, see devlooped/moq#789 for details and links to documentation.) It's the official recommendation and IMHO a great option.

[jonorossi]

Definitely looks like the tooling is much better now. Did you want to give it a go, need to make sure the automated deploys still work for these new packages.