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