Embed PDBs in assemblies so source-stepping works

[thomaslevesque]

Currently, source-stepping with SourceLink doesn't work in some scenarios, due to differences in the SDK behavior. For instance, the .NET Core 3 SDK copies the assemblies from referenced packages to the output folder, but not the PDB (see dotnet/sdk#1458). So the debugger doesn't find the PDB, so it can't find the source.

A simple workaround would be to use the embedded PDB format, which is basically the same as the portable format we're currently using, except that it's embedded in the DLL.

Benefits

• The PDB will always be available, it will no longer depends on whether the SDK copied it or not, leading to a better debugging experience for users.
• Packaging will become simpler, since we don't have to worry about packaging the PDB

Downsides

• The assemblies will be larger.

I don't think the increased assembly size is a major issue ; the PDB is already downloaded with the package anyway. And size itself doesn't really matter, since FakeItEasy is mostly a dev dependency (not shipped with apps). Anyway, the PDB files aren't that big now (about 80KB, when the assembly is around 250KB)

[mikebeaton]

If on a public repo .snupkg is better, and doesn't suffer from the PDB copying problem. It's better because with .snupkg the PDB isn't downloaded at all unless needed, so you're not giving the download overhead to many people who won't want or need it. For private or small audience size repos however, the settings you suggest are fine and much easier to use.

Also note that embedding the PDB and embedding the sources in the PDB are two different things, which don't both have to be done to get sensible output (the alternative to embedding the sources in the PDB is SourceLink).

[thomaslevesque]

Hi @mikebeaton,

Thanks for your input!

If on a public repo .snupkg is better, and doesn't suffer from the PDB copying problem.

We considered it, but we're not sure how well it works outside of Visual Studio. Do other tools support it? VS Code, Rider? Do they know how to download the snupkgs?

It's better because with .snupkg the PDB isn't downloaded at all unless needed, so you're not giving the download overhead to many people who won't want or need it.

True, but:

• We already have that overhead, as we currently have the PDBs in the same package as the assemblies. Nobody complained so far.
• As I mentioned above, the PDBs are pretty small (80KB). This is pretty small compared to the XML documentation files, which are about 360KB each. So the overhead isn't much of an issue.

Also note that embedding the PDB and embedding the sources in the PDB are two different things, which don't both have to be done to get sensible output (the alternative to embedding the sources in the PDB is SourceLink).

We're using SourceLink already. We have no intention of embedding the source code 😉

[mikebeaton]

Okay, I felt like in the discussion you were referencing the MS recommendation and the reasons for it, were getting lost! But as long as that's bourne in mind, I'd agree this seems a perfectly reasonable way forward. I'm afraid I don't know about support in other environments. To check .snupkg support in VS Code, you could try stepping into something in Newtonsoft.Json, which definitely uses it. I think the general idea of symbol servers has standardised and I would guess is pretty widely supported, not just in MS tools.(Not at desk to check, myself!)

…

On Thu, 23 Jan 2020, 09:26 Thomas Levesque, ***@***.***> wrote: Hi @mikebeaton <https://github.com/MikeBeaton>, Thanks for your input! If on a public repo .snupkg is better, and doesn't suffer from the PDB copying problem. We considered it, but we're not sure how well it works outside of Visual Studio. Do other tools support it? VS Code, Rider? Do they know how to download the snupkgs? It's better because with .snupkg the PDB isn't downloaded at all unless needed, so you're not giving the download overhead to many people who won't want or need it. True, but: - We already have that overhead, as we currently have the PDBs in the same package as the assemblies. Nobody complained so far. - As I mentioned above, the PDBs are pretty small (80KB). This is pretty small compared to the XML documentation files, which are about 360KB each. So the overhead isn't much of an issue. Also note that embedding the PDB and embedding the sources in the PDB are two different things, which don't both have to be done to get sensible output (the alternative to embedding the sources in the PDB is SourceLink). We're using SourceLink already. We have no intention of embedding the source code 😉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1751?email_source=notifications&email_token=AC3EU3KJCWAMN3SR2B553HLQ7FPDZA5CNFSM4KKL3LPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJWXAFA#issuecomment-577597460>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3EU3NNSFOLQH7QU5DMUN3Q7FPDZANCNFSM4KKL3LPA> .

[afakebot]

This change has been released as part of FakeItEasy 6.0.1.