Consider switching from Windows PDB (DebugType full/pdbonly) to portable PDB
- Dominant language
- C#
- Stars
- 7.7k
- Forks
- 1.3k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 61
Description
## Summary
WPF explicitly sets `DebugType` to `full` (Debug) / `pdbonly` (Release) for all managed projects via [`eng/WpfArcadeSdk/Sdk/Sdk.props`](https://github.com/dotnet/wpf/blob/e35262208e52547e3f6b50a70b0f3fb4f534b980/eng/WpfArcadeSdk/Sdk/Sdk.props#L55-L56):
```xml
full
pdbonly
```
This means all 70 WPF C# compilations produce Windows-native PDBs instead of portable PDBs.
## Why this matters
1. **Source indexing**: The [source indexer](https://github.com/dotnet/source-indexer) uses `ReadGeneratedFilesFromPdb` (from [complog](https://github.com/jaredpar/complog)) to extract source-generator output and include it in the source index at https://source.dot.net. This API only works with portable PDBs. As a result, all source-generated code in WPF (XAML-generated `InitializeComponent()`, etc.) is missing from the source index. See dotnet/source-indexer#256.
2. **Ecosystem alignment**: The rest of dotnet uses portable PDBs. The .NET symbol pipeline already handles converting portable PDBs to Windows PDBs for native debugging scenarios — so portable PDBs don't prevent Windows-native debugging.
## Recommendation
Consider switching WPF to `portable` (or removing the override to use the SDK default, which is `portable`). The .NET symbol pipeline can produce Windows PDBs from portable PDBs for any native debugging needs.
cc @tommcdon @hoyosjs — would appreciate your thoughts on whether there's a specific reason WPF needs Windows-native PDBs, or if this is a legacy setting that could be updated.
Contributor guide
Assessment
This issue has not been assessed yet.