Check our package building procedure

[jskeet]

Opening one of our packages in NuGet package explorer there are two somewhat alarming aspects:

• The build is non-deterministic
• SourceLink isn't actually working - at least as far as NuGet package explorer is concerned

We should also consider whether or not to change our process around pdb files. Currently we embed them in the nupkg file directly, instead of creating a .snupkg symbols package.
My experience in the past has been that symbol packages have been a pain - partly because for a long time, the default symbol server for NuGet packages simply didn't work.

The main argument against including pdb files appears to be package size, but in our case the pdb files are significantly smaller than either the dlls or the XML documentation files - so I'm tempted to keep them. (Additionally, the size of Grpc.Core dwarfs all of our packages anyway. For example, Grpc.Core version 2.28.1 is 128.36MB. Google.Cloud.Dialogflow.V2 version 3.0.0-beta01 (one of our larger packages) is 598KB. Removing the PDB files and rezipping saves about 120KB of that.

[jskeet]

Looking at the nuspec files we're generating, it looks like we're missing the commit. Not sure why yet.

[jskeet]

dotnet/sourcelink#572 is at least partly to blame - I've got SourceLink validating via the workaround along with some other changes.
(We'll probably want to require SDK 3.1.300 when that's out.)

[jskeet]

For a deterministic build, we need to set DeterministicSourcePaths=true - but only in CI.

[chrisdunelm]

Keeping the pdb in the nupkg sgtm. I agree the size increase is small.