dotnet / dotnet/wpf

Consider switching from Windows PDB (DebugType full/pdbonly) to portable PDB

Open
#11,643 1 comment 4 reactions 0 assignees View on GitHub
area-Build Community Discussion Discuss In WPF Team Triage
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.