Add Sentry support for .NET debug symbols (portable pdbs) to unblock app distribution to customer devices without pdbs.

[asbjornu]

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.

[dcramer]

Hoping to tackle this very soon.

This might be ok to base things on, but likely is too slow because python (also GPL):

https://github.com/moyix/pdbparse

[razzmatazz]

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

[hfjallemark]

Any update on this? Would be great to see the source code within Sentry's stack trace!

[marcomorain]

Related tools from msft: https://github.com/Microsoft/microsoft-pdb

[dwardin]

Any news on this?

[asbjornu]

@getsentry/team, @dcramer: Ping?

[mitsuhiko]

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.

[rollsch]

This probably isn't what people want to hear but what I've personally done this the following:

Obfuscated source code with confuserex and generated reversible naming map file.

Uploading naming map to your api server. Send all sentry reports via your API and de-obfuscate the callstack/etc.

Its a bit ugly but if you want full debugging info in your app without someone being able to open it up in dnspy etc its the only way I could figure out to do it with sentry currently.

[roh85]

Any status updates on this?

[willson556]

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.

[PureKrome]

even better @bruno-garcia is there's really nice SourceLink ability to step into code really easy, in dotnet core.

• https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/sourcelink
• https://github.com/dotnet/sourcelink

simple.
easy to setup.
works like a treat!

[bruno-garcia]

Hi @PureKrome! Thanks for chipping in!

On the SDK side, we've got SourceLink support from beginning:

fe4f617

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 :)

[Green7]

Any status on this?
I see that I can upload pdb files but my stack trace still have no additional information ...

[bruno-garcia]

@Green7 Sorry but this issue was not addressed yet.
I'm interested in more details of your use-case btw.

A few things we'd like to understand are:

1. What type and version of .NET: .NET Framework 4.5, .NET Core 2.0
2. What type of PDB do you use (full, portable).
3. Do you use any obfuscator, if yes, which one?
4. What's the reason not to deploy PDBs with the app. Size constraints? Other?
5. If it was possible to upload your PDBs to Sentry, would be willing to embed the source code in the PDB to get source context (your actual source code around the stack trace lines) in the Sentry dashboard.

[Green7]

1. Net Framework 4.6
2. Full PDB
3. Not now, but I want to use Crypto Obfuscator For .Net Does Sentry .NET supports .NET obfuscators ?  #186
4. Size and security reasons
5. This is a nice feature but it is not essential for me. The most important is stack trace along with the corresponding line numbers of the source code. With this information I can check the source context in VCS.

[Green7]

Any news ?
The stack is useless without pdb files but we don't want to distribute pdb files to our users.
Is there any time line for handling this?

[bruno-garcia]

@Green7 Unfortunately we don't have this work planned at the moment. We'll be looking into what's next for .NET in the upcoming months though.

[bruno-garcia]

@Green7 We need some data to prioritize this. You mentioned .NET Framework 4.6 and full PDB.
Is this a WPF or WinForms or else?
Also, do you plan to move to 4.6.1 anytime soon or .NET Core 3 now that it supports WinForms/WPF?

[Green7]

WinForms. For now we must stay on .Net Framework 4.6 because we still have customers working on Windows Server 2008 or older.

[bruno-garcia]

Now with WinForms and WPF going to .NET Core, I hope we'll set sometime aside to invest in it here at Sentry.

Note that this SDK doesn't support .NET Framework 4.6. Only 4.6.1+. Sentry still has its Raven SDK which supports .NET all the way to 3.5. We maintain it for bugfixes but no new feature are added there though.

Also, I'm curious what type of WinForms app would run on a server. Could you share some info?

[Green7]

We using Raven SDK. We create a computer management application and some customers use it on servers.

[bddckr]

Here's my use case:

• Various .NET Core (3.0+) CLI apps.
• A .NET Core (3.0+) WinForms app.
• A Xamarin.Android app.
• No obfuscator in use, but this might change.
• Size is the main concern for us.
• No interest in embedding the source code into the PDBs currently, but this might change.

[Lonli-Lokli]

Why PDBs are required to be uploaded to Sentry? As for me if we have AWS ECS endpoint (or any other docker-based) PDB can be included in docker image.

[bruno-garcia]

@Lonli-Lokli I'm unaware of a legitimate use case of not publishing server apps with PDBs.
This issue is relevant to client apps (like WPF, WinForms) where the app developer is concerned about either size of the final bundle (less of an issue today with Portable PDBs which are tiny) or more commonly, reverse engineering their code and cloning the app.

[PureKrome]

Out of interest - is this issue not as relevant any more, now that we have Sourcelink integration?

[bruno-garcia]

@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

[MeikTranel]

Any update on this? Does sentry support managed pdb / portable pdbs by now?

[bruno-garcia]

This isn't something we've added yet but I'm bringing this conversation internally to see if we can start planning this.
@MeikTranel could you please share your use case? Is this for Unity? Desktop apps? Do you use obfuscating tools? Do you use an internal NuGet server or how do you track your pdbs?

[MeikTranel]

I have use cases for both desktop and server apps with sourcelink and non sourcelink pens, full and portable symbols as well as obfuscation where we would have to do a relay filter to deobfuscate as well as non obfuscated stack frames

[bruno-garcia]

@MeikTranel It's unclear that we'll cover all of that, of what combinations. To clarify: Obfuscation is a separate topic (tracked here: #186 please add details there like which obfuscation tool you use).

This issue will cover the ability to upload portable PDBs (not Windows PDBs) to Sentry, and .NET stack traces would get symbolicated by it. This will serve Mobile/Desktop use cases (given for server loads it's simpler to embed the pdbs or have them side-by-side since they are tiny).

[PureKrome]

@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) 😄

[bddckr]

Just chiming in here with my team's use case:

• Windows, macOS (Xamarin.Mac), Android (Xamarin.Android) apps (all soon to be on .NET 6)
  • (We've been using stock Sentry .NET for this, not using any Xamarin-specifics or anything here since we share most of our code among the platforms.)
• DebugType is set to portable ✔️

Supporting portable seems reasonable, considering that it's the only supported format starting in .NET 6:

portable is the recommended setting for all projects from now on. The older full and pdbonly settings are for older Windows-specific file formats. .NET 6 and higher will not support those older formats.
https://docs.microsoft.com/xamarin/android/release-notes/11/11.2#deprecation-of-debugtype-full-and-pdbonly

[bruno-garcia]

@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.

[triforcely]

@bruno-garcia would that allow for uploading of "source bundles" as well? I'm currently shipping serverside code with PDBs, so I get line numbers in stack traces but to have the full experience my team would like to see source code as well. AFAIK I can't use sentry-cli to upload source bundles because it doesn't work with .NET PDBs.

[bruno-garcia]

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

[triforcely]

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

That would be great. Will bitbucket be supported?

[Lonli-Lokli]

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

That would be great. Will bitbucket be supported?

Its already supported https://docs.sentry.io/product/integrations/source-code-mgmt/

[mattjohnsonpint]

Let's track this in #1740 going forward. Thanks.

[bruno-garcia]

---

Spoiler alert: getsentry/symbolic#621

[bruno-garcia]

If you're subscribed to this, not just PDB support but source context support landed:

https://twitter.com/brungarc/status/1620877512841777152