Ah; well, that would explain it :) Your PDB files contain no links to source files, which VS and ProGet are unable o index/locate them. This means you'll need to adjust your complication process to incluse them. A quick search surfaced this article, which may be of assistance: Correctly Creating Native C++ Release Build PDBs. Please do post an update if you find the issue/setting in your project/build file that prevented this from happening.

If you don't specify the symbols option, but include everything in a src directory, then it will work. Keep in mind a NuGet package is just a zip file, so if you're having trouble using nuget.exe with nuspec files and native packages, then you might find it easier to workaround by creating the zip file. Just remember to follow the conventions.

Upgraded to 3.7.4 and the problem is fixed. Thanks.

It would be good to clarify the "Symbol and Source Server" document you linked to explain that you don't actually just want to push the symbols package; you want to push a package that contains everything. The way the document currently reads, which is why I got hung up, is that it talks about the two different packages - non-symbols vs. symbols - and then later says to only push the symbol package which is wrong. Symbol packages built with -Symbols don't include content files. I recognize the race condition issue, but the description that symbols packages only differ by adding symbols and source is incorrect. The typical symbol package only has symbols and source.

Thanks Dean - that was super helpful :) I resolved this issue by only promoting the symbols package if one existed. Many thanks!

Do you mean that some symbols are being indexed while others are not?

Now that the current version of Visual Studio seems to respect authentication challenges, we are adding support for this. The tracking issue is here: PG-1273

In short, only push the .symbols package which contains all of the same files in the standard NuGet package, plus the symbols/source. For more info, see: http://inedo.com/support/questions/1409

Sure, when I experienced the problem I simplified the scenario by creating a very simple hello world package and I got the same problem. I'll send that to you.

Is this a NuGet package you can send to us for testing? If not, a Fiddler trace of Visual Studio trying to access symbols would also be helpful. You can send either to support at inedo.com and we'll try to reproduce this.

Proget 3.4.4 Visual Studio fetches the PDB correctly to the symbols cache, but then searches for the source with a local path used on our build server. Sources are not downloaded.

I've just determined that the age is processed, but apparently we are not treating it as a hex number. We'll get this fixed in 3.3.6. Thanks a lot for the detailed analysis!

Guess it depends on the project. I removed -IncludeReferencedProjects on another project we have and that did resolve the issue. Seems to be that if the SRCSRV: {path}\src{ProjectName}{file}.cs not indexed error message contains the project name after src\ then you need -IncludeReferencedProjects. Maybe?

In my case, I was generating the "real" packages in Release build configuration but generating the symbol packages in Debug build configuration. Once I realized the symbol server wouldn't respond correctly when the build configuration differs between the packages, I published the symbol packages in Release build configuration so the packages matched and everything started working correctly. Hope this helps someone else in this same situation!

The feed directory can only contain package files, and remember that a ".symbols.nupkg" is not a valid package file. The ".symbol" file is just a bizarre hack the NuGet team put together to allow you to push half of your package to nuget.org and the other half to symbolsource.org. The nuget.exe client strips the ".symbols" from the name (so the server has no idea what type of file it's receiving). For ProGet, you just have to have everything in a single package... or create a separate feed that the symbol half of your pckage can go to. Basically, you just need to write a script to combine these two files into one. They're just zip files so it should be pretty easy.

It may be as simple as your symbol package getting overwritten. There is no actual difference between a NuGet symbol package and a regular package (except for the file name and the presence of pdb files, and the file name is not submitted with the NuGet push command), so ProGet cannot distinguish between a symbol package and a "non" symbol package. Thus, if you push both, whichever one you push last will overwrite the other one. Can you try changing your process to only push the symbol package and see if that fixes it?

It's unlikely this will be supported. There is no way to identify from metadata a symbol package vs a regular package... you have to open the zip file and see if it contains pdb/src files... which means we'd have to download every version of every package in a remote feed. If Microsoft / NuGet team ever implements a mechanism for identifying , then it's a possibility.

Thanks so much! This has been logged as PG-208, and we plan to fix in the upcoming maintnence release (3.0.4)

Hi, I was having same issue and finally I managed to get mine working. One thing that helps you identify the issue is this using the Module window in VS: Create a console app and install package Add a break point and Run it in VS Open Module window (Main Menu > Debug > Windows > Module) Find your module and check whether the symbols are loaded (in the status) Right-click on the module and click on Symbols Load Information... Thats the main diagnostics that got mine working, what I also had wrong most likely (not too sure about them tho). I was packing this way: Perform an MSbuild on .sln Invoke nuget pack on .csproj e.g. :> pack proj.csproj -sym Instead I'm doing this now: Make sure the bin (output folder) is cleaned. Invoke nuget pack on .csproj with build. e.g. :> pack proj.csproj -sym -build -Prop Configuration=Release Hope it helps.

It's working for us too. Thanks!