New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish symbols to snupkg [DNET875] #805
Comments
Commented by: André Ziegler (andre.ziegler) why? The PDB is embedded to nuget package and this is fine. |
Commented by: @cincuranet Because now http://NuGet.org has official support for symbols/symbol server (https://blog.nuget.org/20181116/Improved-debugging-experience-with-the-NuGet-org-symbol-server-and-snupkg.html). As a side effect the main package will be smaller. |
Commented by: André Ziegler (andre.ziegler) 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! |
Commented by: @cincuranet 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. |
Commented by: André Ziegler (andre.ziegler) The symbol server has other disadvantages: "The http://NuGet.org symbol server only supports the new portable symbol files (*.pdb) created by SDK-style projects. To use the http://NuGet.org 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. |
Commented by: @cincuranet 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. |
Commented by: André Ziegler (andre.ziegler) http://json.net 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 ( https://github.com/NuGet/Home/wiki/NuGet-Package-Debugging-&-Symbols-Improvements#package-consuming-experience ). 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 🤦♂️ |
Commented by: @cincuranet 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 https://symbols.nuget.org/download/symbols. |
Commented by: André Ziegler (andre.ziegler) 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. |
Modified by: @cincuranetFix Version: 6.7.0.0 [ 10900 ] |
Submitted by: @cincuranet
Commits: 4bc0139
The text was updated successfully, but these errors were encountered: