sentry-dotnet: Add Sentry support for .NET debug symbols (portable pdbs) to unblock app distribution to customer devices without pdbs.
As in getsentry/raven-objc#11, we need to add support for debug symbols in the C# client. This requires back-end support from @dcramer and his team, but as soon as that is in place, we should be able to upload .pdb files and have them attached as artifacts to a release.
We did not forget. Sorry for the lack of progress on that front. We’re currently completely revamping our symbol handling for the only platform we provide this at the moment (iOS) and we’re planning on taking those lessons to then hopefully make better progress on other platforms. Ideally we can reuse some of the infrastructure we are building there to also cover C# and other platforms.
@bruno-garcia can you update the thread topic to be more detailed to highlight that this is for mobile/desktop and not about generating pdb’s for the sentry nugets (blush) 😄
I wasn’t aware there was confusion.
To clarify: The Sentry SDK for .NET built in this repo has sourcelink and pdbs available since its inception.
This issue discusses a feature at Sentry where you can upload to Sentry your applications pdbs (usually a concern of client apps where you don’t want to make pdbs available to the customers). And Sentry will use those pdbs to show your proper stack traces with line numbers and file paths.
Supporting portable seems reasonable, considering that it’s the only supported format starting in .NET 6:
Good point. portable pdbs have been available on Mono, .NET Framework (and obviously .NET Core) for many years now and I’m unaware of blockers for anyone to adopt even when using older versions of the framework.
@PureKrome sourcelink will help point you to the source (commit hash and path) but it won’t help .NET give you the line numbers of a function if there’s no pdb around. I believe sourcelink data is stored in the pdb although it’s possible it can be stored in the dll instead
That is to help you debug through the SDK code if you need, and also for a tool like Sentry to display source context if it’s involved in a crash. Which is what I think you meant.
The goal of this issue is to allow customers upload their .NET .pdb to Sentry (which we’d need anyway in order to access the sourcelink data, unless processed/sent by the client which means the client has the PDBs anyway).
This would allow what many desktop apps would want: not release their PDBs with their binaries. Sometimes because of the size constraints (less of an issue with portable PDBs which are ~30% of the size of the binary) but also to make reverse engineering harder.
Right now, if you don’t have the PDBs in the client, the stack traces would actually have no information and we’d need to symbolicate in the processing pipeline in Sentry. We can’t do that right now for .NET PDBs (we’ve recently added support to Native PDBs though).
Sourcelink would allow us to show the code around the affected lines but we’d still need the PDB to symbolicate and also to get the sourcelink data which is embedded in the PDB. And now there are two types of PDBs (old Windows PDB and Portable PDB) so we need to deal with that too 😃
One thing I would like to note is that future VS and mono versions will have an option to generate pdb files that are build accordingly to the new open .PPDB format. See http://tirania.org/blog//archive/2015/Jul.html
Any status updates on this?
We did not forget. Sorry for the lack of progress on that front. We’re currently completely revamping our symbol handling for the only platform we provide this at the moment (iOS) and we’re planning on taking those lessons to then hopefully make better progress on other platforms. Ideally we can reuse some of the infrastructure we are building there to also cover C# and other platforms.
I noticed the following page in the docs recently: https://docs.sentry.io/cli/dif/pdb/
I haven’t had chance to try it yet but it looks promising.
Any news on this?
If you’re subscribed to this, not just PDB support but source context support landed:
https://twitter.com/brungarc/status/1620877512841777152
Its already supported https://docs.sentry.io/product/integrations/source-code-mgmt/
That’s correct, source bundles isn’t support yet. We are planning on doing stacktrace linking though: https://docs.sentry.io/product/integrations/source-code-mgmt/github/#stack-trace-linking
I wasn’t aware there was confusion. To clarify: The Sentry SDK for .NET built in this repo has sourcelink and pdbs available since its inception. This issue discusses a feature at Sentry where you can upload to Sentry your applications pdbs (usually a concern of client apps where you don’t want to make pdbs available to the customers). And Sentry will use those pdbs to show your proper stack traces with line numbers and file paths.
Good point. portable pdbs have been available on Mono, .NET Framework (and obviously .NET Core) for many years now and I’m unaware of blockers for anyone to adopt even when using older versions of the framework.
Just chiming in here with my team’s use case:
DebugTypeis set toportable✔️Supporting
portableseems reasonable, considering that it’s the only supported format starting in .NET 6:@PureKrome sourcelink will help point you to the source (commit hash and path) but it won’t help .NET give you the line numbers of a function if there’s no
pdbaround. I believe sourcelink data is stored in thepdbalthough it’s possible it can be stored in thedllinsteadHere’s my use case:
Hi @PureKrome! Thanks for chipping in!
On the SDK side, we’ve got SourceLink support from beginning:
https://github.com/getsentry/sentry-dotnet/commit/fe4f617d6c9600105e45f6542c4c90538f2269b6
That is to help you debug through the SDK code if you need, and also for a tool like Sentry to display source context if it’s involved in a crash. Which is what I think you meant.
The goal of this issue is to allow customers upload their .NET
.pdbto Sentry (which we’d need anyway in order to access the sourcelink data, unless processed/sent by the client which means the client has the PDBs anyway).This would allow what many desktop apps would want: not release their PDBs with their binaries. Sometimes because of the size constraints (less of an issue with portable PDBs which are ~30% of the size of the binary) but also to make reverse engineering harder.
Right now, if you don’t have the PDBs in the client, the stack traces would actually have no information and we’d need to symbolicate in the processing pipeline in Sentry. We can’t do that right now for .NET PDBs (we’ve recently added support to Native PDBs though).
Sourcelink would allow us to show the code around the affected lines but we’d still need the PDB to symbolicate and also to get the sourcelink data which is embedded in the PDB. And now there are two types of PDBs (old Windows PDB and Portable PDB) so we need to deal with that too 😃
One thing I would like to note is that future VS and mono versions will have an option to generate
pdbfiles that are build accordingly to the new open.PPDBformat. See http://tirania.org/blog//archive/2015/Jul.html