ProGet 4.x and 5.x symbol server

I wasn't able to get source/symbols server to work on ProGet 4.8.x so I updated to 5.0.2 to see if this would be resolved. On the Manage Feed page Symbol Server says disabled but if I click Configure the checkboxes are both enabled. Whatever the value of the checkbox it always says disabled (behavior persists when deleting/recreating the feed).

I am generating my symbols.nupkg with --include-symbols --include-source and I have added <DebugType>Full</DebugType> to my SDK csproj file which targets only .NET 4.6.1. I can push the package to ProGet just fine but when I view the package in the web UI I don't see anything about source/symbols being present.

How do I get ProGet to recognize source/symbols?

Product: ProGet
Version: 5.0.2

ben

Hello Boyd,

Your first question is a visual error (the symbol server is actually enabled, but the feed management page shows disabled due to a bug) - issue number PG-1169.

For the second question, on the package page, under the Files tab, does the lib\net461 folder contain a PDB file? Symbols built with <DebugType>Full</DebugType> should work. The only debug type ProGet doesn't currently support is Portable.

Hi Ben,

Is there a way for me to upload images here? I have a screenshot with my nuget package which includes a src folder as well as the pdbs next to the dlls. I am sure I am building with <DebugType>Full</DebugType>. Is there some endpoint I can easily hit to debug whether or not symbols are being served? It still does not seem to work inside VS.

Thanks,
Boyd

I just want to add that I see a 404 when hitting /symbols/app-dev-shared but am able to hit our package site /nuget/app-dev-shared just fine.

ben

For images, you can upload them to an external site (such as imgur) and use the photo button on the toolbar.

Symbols are accessed through this path: /symbols/[feed name]/[dll name].dll/[guid without hyphens]/[pdb name].pdb

So for the example in the image, the URL Visual Studio would request would be http://proget-url/symbols/NuGet/Bar.dll/872237e9cd584333bbe489f59ab9c89b/Bar.pdb

Just to be clear, you're only uploading the .symbols.nuget version of the package, right? If you upload the version that is just .nuget, it will overwrite the package that's already there with one that doesn't have symbols.

Hi Ben,

Thanks for that URL but where does the guid come from?

I double checked our TeamCity builds and we are definitely only publishing the symbols package. I checked the file directory on the ProGet server for my package and it does contain src and symbols as expected. I also disabled the "Strip symbol files from packages downloaded from this feed" option and then downloaded a package which also contains src and symbols.

Thanks,
Boyd

GUIDs are part of a PDB header, and are generated by the compiler. This is what visual Studio asks for when seeking a PDB. ProGet just reads the .pdb files, and returns the appropriate symbol when requested.

Is it the same version guid generated on the dll? I tried hitting the endpoint using the guid from the dll as I'm not sure how to pull it from the pdb.

http://feeds.elliottmgmt.com/symbols/app-dev-shared/Elliott.Moat.Api.dll/2e9a5d53f79c495daec2459b8d69d78f/Elliott.Moat.Api.pdb

As you can see in my previous message everything is in place on the nuget side but loading symbols in VS does not pull any of my package pdbs in to the local symbols cache. I also don't see the symbols button when viewing the package in nuget. This will be a pretty large blocker for us going forward with ProGet.

Please advise.

Thanks,
Boyd

I really don't know how MSBuild/cs.exe/whatever generates those GUIDs, nor do I know how visual studio "knows" which GUID to request based on a particular DLL... but ProGet indexes whatever GUID is in the .pdb files you upload, and sends those .pdb files whenever you request it via that GUID.

If visual studio is requesting the "wrong" GUIDs, then somehow it's using the "wrong" DLL. Check the guide here for how to troubleshoot this: https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server

ben

If the PDB files aren't being indexed by ProGet, it's possible that ProGet can't read them for some reason.

Try compiling this program with references to ProGetCoreEx.dll and InedoLib.dll from your version of ProGet and a reference to the System.Reflection.Metadata NuGet package and then dragging and dropping your nupkg file onto the resulting exe.

If you don't care about portable PDB files, you can also skip adding the reference to System.Reflection.Metadata and remove the code between the comments.

using Inedo.ProGet.Feeds.NuGet;
using Inedo.ProGet.Symbols;
using System;
using System.IO;
using System.IO.Compression;
using System.Linq;

namespace ReadPDB
{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length != 1 || !args[0].EndsWith(".nupkg") || !File.Exists(args[0]))
            {
                Console.Error.WriteLine("Usage: ReadPDB [PackageName].nupkg");
                Environment.ExitCode = 1;
                return;
            }

            using (var zipFile = new ZipArchive(File.Open(args[0], FileMode.Open, FileAccess.Read)))
            {
                var pdbEntries = zipFile
                    .Entries
                    .Where(e => e.FullName.EndsWith(".pdb", StringComparison.OrdinalIgnoreCase));

                foreach (var pdbEntry in pdbEntries)
                {

                    using (var pdbStream = SeekableStream.Create(pdbEntry))
                    {
                        try
                        {
                            using (var pdbFile = new PdbFile(pdbStream, true))
                            {
                                Console.WriteLine($"PDB successfully read: {pdbEntry.FullName}");
                                Console.WriteLine($"GUID: {pdbFile.Guid}");
                                Console.WriteLine($"Age: {pdbFile.Age}");
                            }
                        }
                        catch (Exception ex)
                        {
                            // Start removing here if you don't want Portable PDB detection
                            try
                            {
                                pdbStream.Position = 0;
                                using (var pdbProvider = System.Reflection.Metadata.MetadataReaderProvider.FromPortablePdbStream(pdbStream, System.Reflection.Metadata.MetadataStreamOptions.LeaveOpen, (int)pdbEntry.Length))
                                {
                                    var portablePdb = pdbProvider.GetMetadataReader();
                                    Console.WriteLine($"Portable PDB (not yet supported in ProGet): {pdbEntry.FullName}");
                                    Console.WriteLine($"ID: {BitConverter.ToString(portablePdb.DebugMetadataHeader.Id.ToArray())}");
                                }
                            }
                            catch
                            // Stop removing here if you don't want Portable PDB detection
                            {
                                Console.WriteLine($"Exception reading PDB: {pdbEntry.FullName}");
                                Console.WriteLine(ex);
                            }
                        }
                    }
                    Console.WriteLine();
                }
            }
        }
    }
}

I ran it on an AWS SDK package I had handy and got this output:

Portable PDB (not yet supported in ProGet): lib/net35/AWSSDK.Core.pdb
ID: 5A-C8-40-60-8B-E5-A0-41-80-C7-EE-B9-8C-A0-5B-A0-A0-62-05-B0

Portable PDB (not yet supported in ProGet): lib/net45/AWSSDK.Core.pdb
ID: 4F-87-A8-84-3D-D1-C0-47-AE-87-C2-31-06-3A-6E-1E-F3-FD-D4-B4

PDB successfully read: lib/portable-net45%2Bwin8%2Bwpa81%2Bwp8/AWSSDK.Core.pdb
GUID: dc8ebad0-50a8-472e-9cc3-60532a217cbc
Age: 1

PDB successfully read: lib/uap/AWSSDK.Core.pdb
GUID: a397a2d1-0d7d-421c-a439-2035263a60aa
Age: 1

PDB successfully read: lib/MonoAndroid10/AWSSDK.Core.pdb
GUID: 30508864-ead4-403e-9a70-7cf92ddc62b3
Age: 1

PDB successfully read: lib/win8/AWSSDK.Core.pdb
GUID: 03674990-484c-4e12-a418-95b02a794ceb
Age: 1

PDB successfully read: lib/wpa81/AWSSDK.Core.pdb
GUID: a397a2d1-0d7d-421c-a439-2035263a60aa
Age: 1

PDB successfully read: lib/wp8/AWSSDK.Core.pdb
GUID: 73cde1a1-208e-4146-84d0-556fa77badc1
Age: 1

Portable PDB (not yet supported in ProGet): lib/netstandard1.3/AWSSDK.Core.pdb
ID: 54-A2-57-38-16-AB-F1-42-A8-90-4B-6B-4E-F1-9A-FA-2F-72-9D-C7

Hi Ben,

I just lost a rather lengthy message I was typing out here, must've been due to a timeout.

Anyways, i was able to use your utility and my package said PDB successfully read. I don't see the "Symbols & Source" message appear on ProGet for this package as specified in the link shared by Alana. At the moment I don't have time to go through the troubleshooting steps in the same link. I did try loading symbols in VS and still don't see as expected in the cache but not sure if that is a complete test. When I have time I will go through the troubleshooting steps and report back.

Thank you both so much for your time and help.

Thanks,
Boyd

Hi All,

So I've made some progress and I have the pdb files downloaded to the project referencing my nuget package!

The last hurdle I face is that the exact line causing the exception within my library is not displayed. VS still cannot find the source code for the library. If I set a breakpoint and hit F11 to step-into it prompts me to locate the .cs file. The guide doesn't mention how to troubleshoot this and my nuget package definitely contains a src folder at the root level.

Are there any other steps you can recommend to get the source linked properly?

Thanks,
Boyd

I had this same problem with a bare install of 5.0.3 (build 7?). Installed on Sql Server with IIS.

Built the solution with the pdb
Packaged with -Symbols and included source
Published only the .symbols.nupkg
In ProGet - "Source and Symbols" does NOT display
Explore the "Files" tab and my pdb and source files are there, exactly where they should be.
navigate to <<proget install>>/symbols/<<feed>> and get nothing but a 404

I downgraded to 4.8.9 (build 2) installed with the built-in web server and Sql Server and all my problems went away.

Notably:

Source and Symbols DOES display
Navigate to <<proget install>>/symbols/<<feed>> does NOT give me a 404, it gives me an actual page explaining how to use VS and the Symbol Server

ben

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.