pdb files with .NET 8

[tmds]

For .NET 6 and 7, pdb files didn't work as they went looking for the distro sources that .NET was compiled from (#2623).

With .NET 8, things should be better thanks to the sourcelink integration.

Has someone verified this to work?

If there are working pdbs:

• should the vmr output include them by default, or should it be opt-in?
• if they are opt-in, what are the steps? Can we document them? Or enable the opt-in through a build-flag?
• is it recommended to package the pdbs separate, or include them in a package with their dlls?

cc @dotnet/distro-maintainers @MichaelSimons @premun @omajid

[tmds]

should the vmr output include them by default, or should it be opt-in?
if they are opt-in, what are the steps? Can we document them? Or enable the opt-in through a build-flag?
is it recommended to package the pdbs separate, or include them in a package with their dlls?

After giving it some thought, I think it would make sense to include the pdbs by default at the right location in the vmr output.

It's then up to the package mantainers to remove or package them up. And some guidelines can be written for that.

[NikolaMilosavljevic]

@tmds every .NET repo produces symbols packages by default. We are just not packaging them into Intermediate packages due to https://github.com/dotnet/arcade/blob/163ea52a2a7065f26e2d49e39e863ccad043c650/src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcade.targets#L83-L84

Every NuGet package has a matching symbols.nupkg that includes the same contents, plus PDBs right next to binaries. You can see all these packages in VMR build, under each repo's artifacts.

I'm proposing that we include all these symbols.nupkg in Intermediate packages, so they end up in VMR's artifacts location (blob-feed/packages). This change would be for full product source-build only. This would enable distro maintainers to consume PDBs, publish them, or just delete these new packages. It would further enable us to do sourcelink verification of a full product source-build (#3052).

Of course, we would not add these symbols packages to previously-source-build archive.

[tmds]

@NikolaMilosavljevic will this (or can we) make it so that the pdbs of the .NET Core and ASP.NET Core shared framework are included in the output tarball by default?

[NikolaMilosavljevic]

The proposal is to not add these new 'symbols' packages to Private.SourceBuilt.Artifacts` tarball, to keep its size smaller. Would it be valuable to have an option to do that?

Runtime repo produces a symbols-only tarball and it is available today in source-build artifacts drop - i.e. artifacts/x64/Release/runtime/dotnet-runtime-symbols-[rid]-[version].tar.gz There isn't anything similar for aspnetcore.

My proposal would unify the experience and cover not only runtime and aspnetcore but also all other repos producing managed assemblies, and make those PDBs available under artifacts at the end of source-build. Those repos include nuget.client, sdk and others.

[mmitche]

I agree with @NikolaMilosavljevic that the right thing to do is to align Microsoft's build and source-build on .symbols.nupkg for both the shared frameworks as well as nuget packages. That would also mean that a move to using .snupkgs would be seamlessly supported in source-build.

[tmds]

The proposal is to not add these new 'symbols' packages to Private.SourceBuilt.Artifacts` tarball

I wasn't referring to the Private.SourceBuilt.Artifacts tarball.

The request is to include the pdbs for .NET and ASP.NET runtime with the other files that need to be packaged by the distro maintainer.

It seems simpler to include these files in the output than to have a package maintainer extract them separately using additional nuget packages that are produced by the build.

[mmitche]

@tmds Wouldn't that mean less flexibility for the maintainer? The pdb sizes are pretty significant. If the pdbs are included with the runtime archive by default, for instance, it would more than double the download size (30 MB of binaries + 38 MB of pdbs for the Linux x64 archive).

[tmds]

The thinking is: the maintainer is anyhow responsible for slicing up the output into packages. He can deal with the pdbs the way he wants, which could be to just delete them, but preferably to package them in some way.