Are snupkg files supposed to be tiny?

[taori]

Please verify this: https://ci.appveyor.com/project/taori/amusoft-ui-wpf/builds/21730035/artifacts

the snupkg seems off? Is 2kb really correct, or is there something wrong with it? There's little documentation at the moment to see how to get a proper package out of this.

#229 makes it sound like "portable" has to be the DebugType in the csproj - is that correct or does "embedded" work as well?

[tmat]

The linked snupkg is empty, which is not right. It should contain PDB files.

Yes, DebugType should be "portable", which is the default when you create a new .NET Standard or .NET Core App project.

[taori]

Is my build script wrong, or should it be working? I assume it should be working if it generates artifacts and does not fail. Perhaps you have an idea what's wrong here.

https://ci.appveyor.com/project/taori/amusoft-ui-wpf/builds/21730452 is built with -p:DebugType=portable and packed with --no-build, which should override the project settings unless i'm wrong.

[tmat]

Why not just set portable here? https://github.com/taori/Amusoft.UI.WPF/blob/master/src/Amusoft.UI.WPF/Amusoft.UI.WPF.csproj#L26

And also delete this line:
https://github.com/taori/Amusoft.UI.WPF/blob/master/src/Amusoft.UI.WPF/Amusoft.UI.WPF.csproj#L36

and add

    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>

instead.

[taori]

I'll try that thanks - copied those settings from newtonsoft.json.

Also the reason why i set it to embedded, was because i read that it cuts down on the time it takes to load symbols. Is there even any benefit of using snupkg though versus nupkg+embedded?

[tmat]

We recommend snupkg because the main library package is smaller as it does not contain PDBs.
Most of your customers will likely not need the PDBs, so it doesn't make sense to burden them with the extra package size. Those customers who will debug thru your library will get the symbols from the symbol server. Once the symbols are on their machine they are cached, so the next debugging session will fetch them locally without downloading anything from the server again.

[taori]

I see. Thanks for the clarification.
Are these assumptions right then?

• snupkg is the replacement for the old symbols.nupkg, which provides debugging functionality in a repository based infrastructure
• snupkg contains pdb data only
• pdb's in snupkg are much, much smaller compared to before (see this) which is caused by portable pdb files being much smaller than their old counterpart (+20% of the assembly they are built for)
• the old nupkg with --include-source is currently is the only way to have source link work offline / without repository ?

[tmat]

Yes. Yes. Yes. No.

the old nupkg with --include-source is currently is the only way to have source link work offline / without repository ?

It depends on what you mean offline. Do you mean you restore online then go offline and try to debug?

If you want to allow debugging without access to the repository you can set EmbedAllSources which embeds the sources to the PDB. Then you need to have the PDB available when debugging.

[taori]

Yes - I also mean it in a wlan scenario, where the connection may be flaky or internet access is suddenly restricted.

Am i getting you right then, that EmbedAllSources is a switch which shall be used for snupkg too? Because judging by documentation cs files would be a filtered extension.

[tmat]

EmbedAllSources will embed the (compressed) sources into the PDB, it will not add the source files to the package directly.