Skip to content

Fix the issue where PDBs generated by ILSpy do not match certain asse… #3629

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
siegfriedpammer merged 1 commit into from
Dec 21, 2025
+2 −1
Merged

Fix the issue where PDBs generated by ILSpy do not match certain asse… #3629

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion ICSharpCode.Decompiler/DebugInfo/PortablePdbWriter.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -235,8 +235,9 @@ string BuildFileNameFromTypeName(TypeDefinitionHandle handle)

if (pdbId == null)
{
var debugDir = file.Reader.ReadDebugDirectory().FirstOrDefault(dir => dir.Type == DebugDirectoryEntryType.CodeView);
var debugDir = file.Reader.ReadDebugDirectory().LastOrDefault(dir => dir.Type == DebugDirectoryEntryType.CodeView);
Copy link
Member

@siegfriedpammer siegfriedpammer Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it always guaranteed to be the last entry? Wouldn't it make more sense to check that the extension is not .ni.pdb?

I did some testing by scanning all the .dlls on my machine and reading the DebugDirectory and it seems that at least the Microsoft compiler puts the non-native image entry last.

Copy link
Contributor Author

@sonyps5201314 sonyps5201314 Dec 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I actually considered adding a line like Debug.Assert(!portable.Path.EndsWith("ni.pdb")); for more robust verification, or to alert us to unexpected scenarios in the future.

However, after checking dotPeek's code, I noticed that they always iterate from the end. Trusting their implementation, I decided to simply omit that assertion.

Copy link
Member

@siegfriedpammer siegfriedpammer Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, could you add a comment to document the assumption? Thank you!

Copy link
Contributor Author

@sonyps5201314 sonyps5201314 Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, feel free to modify this further, or we can wait until an unexpected scenario arises before making adjustments.

Arguably, the most reliable method would be to reverse engineer the relevant code in the VS debugger to confirm the exact matching logic. However, I suspect that dotPeek has already done this, which is why I decided to adopt an approach similar to theirs.

Copy link
Contributor Author

@sonyps5201314 sonyps5201314 Dec 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, could you add a comment to document the assumption? Thank you!

I didn't know how to describe this assumption, so I simply added a call to Debug.Assert in the latest commit to execute this assumption.

var portable = file.Reader.ReadCodeViewDebugDirectoryData(debugDir);
Debug.Assert(!portable.Path.EndsWith(".ni.pdb"));
pdbId = new BlobContentId(portable.Guid, debugDir.Stamp);
}

Expand Down
Loading