Question: I saw in one of your examples that you created a package for libraries and another for symbols. After consuming the packages, the user was able to debug and step through the code. Is it best to create only a .nupkg with libraries? A .nupkg with libraries and PDB's? A .nupkg and a .symbols.nupkg?

Answer: As always in our industry, "it depends".

The big plus of having them together in one package: symbols are there all the time. This makes debugging and profiling etc. a breeze - except that symbols are symbols, not sources. So shipping libraries and symbols in one package does not necessarily mean you can debug and step through source code. Symbols describe the original program structure and provide pointers to the source code. They don't provide the source code though...

With classic .NET, the way symbols work is that they PDB needs to be indexed for debugging to work, something which NuGet does not do. By using NuGet's -Symbols switch to create bot the .nupkg and .symbols.nupkg, it does provide MyGet with all that is needed to perform this indexing step and host symbols and sources. So using our MyGet symbol server and separate packages, we provide that bridge between symbols and showing actual sources.

This only works with separate packages: if the PDB is in the original package, Visual Studio will never reach out to the symbol server to perform that last bridge step. Shipping one package with libraries and symbols is fine, but you'll have to perform indexing manually if you also want to do source stepping.

With .NET Core, a new way of indexing exists, called SourceLink, where the compiler embeds symbols and sources, and one package works just fine if you plan on source code stepping.

So in short: want symbols? The choice doesn't matter. Want symbols and source stepping? Either use SourceLink and one package, or two packages and MyGet's symbol and source server (bonus is we add authentication, too).