Hi @patrick-groess_2616 , The /symbols/<feed-name> URL is only for Visual Studio's Symbol Location setting, and is used to download symbols. Do not try to use it with nuget.exe, it will give that error. You need to use /nuget/<feed-name> to push symbol or nuget.exe packages. Thanks, Alana

Hello, Sorry for the confusion. For your solution you would need two separate feeds. One for normal package, one for symbols. Thanks, Jason

Apologies, I had seen the StackOverflow post first, so I responded here: https://stackoverflow.com/questions/56338757/proget-symbols-and-source-server-download-pdb-correctly-but-source-not-found/56397293#56397293

Hi Anderson , Of course, a lot of our customers host ProGet in the cloud, and just install it on their own server in the cloud. But, we found it wasn't so popular to pay us to do that. The pricing was basically hosting costs + license costs + overhead, so something like $150/mo, depending. We stopped offering it, because we found most customers were either looking for a cheap, multi-tenant service (like $20 to $50/mo), or for really advanced infrastructure far beyond our capabilities (like dozens of servers globally linked, at like $10k/mo+). We are planning to launch “bring your own license” VM/Container in the cloud services at some point, and may leverage that as a hosted option. Any datapoints or insights you might have are always welcome, and I’ll share those to our leadership!

Please check the Symbol and Source Server; basically you will want to use a symbols feed. The /symbols endpoint is not a Nuget feed, so you can't push packages to it.

Yes, we're currently using dotnet nuget push to push packages. We're using the "legacy" *.symbols.nupkg format, though, to be safe.

This will be fixed in PG-1273 for the next maintenance release.

You'll want to push a "combined" symbols package to http://🚫/nuget/feed-name - the symbols endpoint is for downloading extracted symbols only. Check out the guide we have at Symbol and Source Server docs for more info

Please have your colleague follow the instructions in Source and Symbol Serving; it's easy to miss one small detail, and then in this case, it won't work.

From what I understand "portable" PDBs were introduced with dotnet core. This is some legacy code that is written in vb.net and is using the full .net framework. As far as I know it is just a traditional windows PDB.

We've been holding to v5.0.6 because it appears this issue is still open and was introduced (as far as we can tell) in 5.0.7: https://inedo.com/support/questions/8240 Has this been addressed in the latest build for linux on docker?

I like it, good idea. I've put in a feature request for it, PG-1213 - so if it's possible to do it easily and in a mainteance release well do it! Stay tuned.

Were on it! THe issue is that it's the "new" symbol format. The feature is PG-1054 and we will ship it in a maintenance release soon :)

Thank you, I was not aware of this. Seems to work

As a followup, support for the Portable PDB format in the symbol/source server has since been added to ProGet.

Thanks Alana. We double checked the PDB files that were being created, and only the .NET 4.5 version was a "full" PDB. After additional investigating we have found the issue. When working with a SDK style project in Visual Studio 2017, the UI does not accurately set the DebugType Full property in the project. For us it left a condition on the PropertyGroup which only applied the DebugType Full element to the net45 version of the assembly. After removing that condition, we are now getting full PDBs created for each version of the assembly.

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database. The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

Please find some helpful tips for symbol server diagnosing here. https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server If the GUID is incorrect, then you certainly have the incorrect PDB file locally. It's perhaps embedded in your NuGet package (which will cause problems, since it can't point to a source server), or is being pulled from a cache elsewhere on your disk.

Is it a "Portal PDB"? This is the new format and is not yet supported. If not, then the next step would be for you to submit a ticket with the NuGet package attached so that we can debug the pdb parsing.

Just to clarify, .NET PDBs with "full" debugging information (i.e. Windows PDB format) are supported, it is just .NET "portable" format that is currently not supported. Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md Unfortunately at this time we don't have a timetable for if or when this gets implemented.