Skip to content

Documents node in embedded PDB different in .NET Core 3 #1

@daveaglick

Description

@daveaglick

This intrigued me and I've been meaning to dig into how SourceLink works anyway, so here we are. I think I know what's going on...or at least why it's failing. I just don't know how to fix it.

For starters, here's the embedded PDB metadata of a build on .NET Core SDK 2.2.401:

2020-01-28_21h45_52

And here's the embedded PDB metadata of a build on .NET Core SDK 3.1.101:

2020-01-28_21h39_40

There's so much more! But most importantly, check out that "Documents" node. It doesn't even exist in the .NET Core 2.2 build.

This can be verified by the sourcelink tool - here it is listing documents for the 2.2.401 build:

>tools\sourcelink print-documents bin\Release\netstandard2.0\dotnetcore-sourcelink-test-bug.dll

>

Well that was anticlimactic. Here it is for the 3.1.101 build:

>dotnet sourcelink print-documents bin\Release\netstandard2.0\dotnetcore-sourcelink-test-bug.dll
8c4deb227a4346af8cf4e320a3d78efdce7dd602bc423d79cd2d448dbb9ffc41 sha256 csharp C:\Code\Experiments\dotnetcore-sourcelink-test-bug\Class1.cs
a529e7a12beb0f9db49ac28387cf2d33b2dc765f7d70b604834a085118757966 sha256 csharp C:\Code\Experiments\dotnetcore-sourcelink-test-bug\obj\Release\netstandard2.0\dotnetcore-sourcelink-test-bug.AssemblyInfo.cs
a6e03ae4df13fe05345e9022d1f1cd24ecae4bfd66db4843697c855d9f9335f4 sha256 csharp C:\Users\dglick\AppData\Local\Temp\.NETStandard,Version=v2.0.AssemblyAttributes.cs

>

I'm pretty sure that confirms the sourcelink tool is using the Documents node in the PDB. Just to be sure, I peeped the sourcelink tool code (which isn't in the DNF repo, but in a repo from @ctaggart directly):
image

Here's the actual code for the test command: https://github.com/ctaggart/SourceLink/blob/be8dcdaad09a2891bc0e1d04e43af40a1e482158/dotnet-sourcelink/Program.cs#L203

If we go back and look more closely at the output from test when it fails:

>dotnet sourcelink test bin\Release\dotnetcore-sourcelink-test-bug.1.0.0.nupkg
1 Documents without URLs:
a6e03ae4df13fe05345e9022d1f1cd24ecae4bfd66db4843697c855d9f9335f4 sha256 csharp C:\Users\dglick\AppData\Local\Temp\.NETStandard,Version=v2.0.AssemblyAttributes.cs
1 Documents with errors:
a529e7a12beb0f9db49ac28387cf2d33b2dc765f7d70b604834a085118757966 sha256 csharp C:\Code\Experiments\dotnetcore-sourcelink-test-bug\obj\Release\netstandard2.0\dotnetcore-sourcelink-test-bug.AssemblyInfo.cs
https://raw.githubusercontent.com/shiftkey/dotnetcore-sourcelink-test-bug/e707de6428305d6a2bd997a516b5444592421cfd/obj/Release/netstandard2.0/dotnetcore-sourcelink-test-bug.AssemblyInfo.cs
error: url failed NotFound: Not Found
sourcelink test failed
failed for lib/netstandard2.0/dotnetcore-sourcelink-test-bug.dll
1 files did not pass in bin\Release\dotnetcore-sourcelink-test-bug.1.0.0.nupkg

We can see two errors which make sense to me now because we can track them back to entries in the PDB metadata as document nodes:

TL;DR:

  • Lots of extra PDF metadata is getting added when using the .NET Core SDK 3.1.101
  • This extra metadata includes document nodes for generated files
  • The sourcelink tool reads those nodes from the embedded PDB and has no idea they're not actual source files

I'm left with the following questions:

  • Why is the 3.1.101 SDK generating these document nodes in the embedded PDB but earlier SDKs are not
  • Are the document nodes "correct" in the sense that not generating them was actually the wrong behavior?
  • Does the sourcelink tool need to know how to identify and deal with (or ignore) generated AssemblyAttributes.cs, AssemblyInfo.cs, and other generated source files?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions