dotnet
Migrate all repos to .snupkg
Currently some repos include Portable PDBs in packages, others produce .Symbols.nupkg.
All projects that produce Portable PDBs should package them to .snupkg. This policy should be the default and enforced by Arcade SDK.
Is there any update on this one ? The workaround here https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/Workarounds.targets#L60 makes it difficult to not include symbols in the package
@markwilkie is this on your team's radar? It would be great to standardize on .snupkg.
This is not on our radar right now. What do you see as an infra update that would make sense? You thinking enforcement?
I referenced the relevant issue in ASP, but adding here so context doesn't get lost on work that needs to happen before this is viable for dotnet.
snupkg is an advantage in the sense that they are indexed to NuGet and that they are lighter. There are a few problems with them right now for our use:
- They don't support full Windows PDBS - so they don't support native code, only managed portable PDBS.
- We need DLLs indexed into our symbol servers. From a debugging perspective, sourcelink-enabled PDBs with embedded untracked source do the work for debugging, but this is just source debugging. For dump debugging, DLLs are often needed as they contain metadata that's needed but that is often not available in the dumps (comming from desire to avoid collecting full dumps for file size reasons and some PII protected scenarios where most info is stripped). This is crucial for things like Watson and SOS. Currently, as @riarenas pointed out, V3 publishing only tries to publish the symbol packages so this would need to change.
Microsoft Symbol servers (symweb and MSDL) index all of this for us and they have public accessibility as needed. NuGet symbol servers make a lot of sense if you are an external customer/OSS project that wants to index symbols. Unless I am missing something the only thing they provide for us is cost savings on the per-repo payload size. If this is a concern, or if there's a customer scenario that I am missing we should consider this. Otherwise, I am not sure this gives us much of a benefit and requires quite a few changes in the overall dotnet infra.
