ProGet 4.x and 5.x symbol server

[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.

[Guest]

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

[Guest]

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.

[Guest]

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

Thanks,
Boyd

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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.