Issue Details (XML | Word | Printable)

Key: DNET-875
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Jiri Cincura
Reporter: Jiri Cincura
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
.NET Data provider

Publish symbols to snupkg

Created: 11/Apr/19 06:53 AM   Updated: 24/Jul/19 11:35 AM
Component/s: NuGet packages
Affects Version/s:
Fix Version/s:

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
André Ziegler added a comment - 11/Apr/19 06:29 PM
why? The PDB is embedded to nuget package and this is fine.

Jiri Cincura added a comment - 12/Apr/19 06:10 AM
Because now has official support for symbols/symbol server ( As a side effect the main package will be smaller.

André Ziegler added a comment - 12/Apr/19 06:18 AM
symbol servers suck and MUST die. I can put the downloaded nuget package on a share, isolated from Internet and can debug it because it has PDB. Now I require internet excess. In case symbol server has issues (which happens often for Microsoft symbol server) you can't debug firebird related issues. DON'T support this nonsense!

Jiri Cincura added a comment - 12/Apr/19 06:24 AM
You need internet access to download the main nuget package anyway. While doing that, you can grab the snupkg and place it on a share as well.

André Ziegler added a comment - 12/Apr/19 06:50 AM
The symbol server has other disadvantages:

"The symbol server only supports the new portable symbol files (*.pdb) created by SDK-style projects.

To use the symbol server when debugging a .NET library, developers must have Visual Studio 2017 15.9 or later."

So you kill all 15.x users under 15.9 (Some users may have a blocking issue that it not fixed in 15.9, I was also forced to stay for longer time at 15.5.7 because 15.6 and 15.7 had issues that were later fixed in 15.8)

And users have to manually add symbol server (automatically done in 2019 update 1) to VS configuration.

If symbol server goes done or uploading fails users are also unable to step into your lib code.

Summary hasn't changed, extra symbol server always sucks as they cause extra work/limitations and add new ways where something can go wrong.

Jiri Cincura added a comment - 12/Apr/19 11:27 AM
We already publish portable PDBs. No change here. And if you don't want to update, you don't have to. You can always stay on current version of your tools as well as provider. And again, you download the symbols just once - yes your connection can be down, nuget can be down, ... Yet we still use nuget for packages.

André Ziegler added a comment - 29/Apr/19 07:57 AM has done it with 12.0.2, now I've done the nuget update and guess what happens? Right, VS2017 fails to download the symbol, even if I have added nuget symbol server to VS options ( ).

So it happens what I expected. If I would now have an json issue I were not able to find a pdb and debug it 🤦‍♂️

Jiri Cincura added a comment - 29/Apr/19 08:17 AM
The document you linked seems to be outdated, because it still mentions the "old" symbol server (which was basically 3rd party solution). The URL for NuGet's own is

André Ziegler added a comment - 07/May/19 07:12 AM
nothing worked for me in VS2017, in a 2nd VM with 2019 16.1 it works.

On the main dev VM I've downloaded and extracted the json symbols package to .nuget/packages folder to restore the pdb next to dll to emulate the older way. Now I have the PDBs.

I'll also have to do this when you implement this.