Proget and Symbol/Source server not delivering source stepping

tbl_5153

Publishing a package containing source and symbols, packaged using the Nuget -symbols command, does provide symbols but not source stepping.

Visual Studio will only step into local code.

It is my understanding that Proget strips a Symbols package for the PDB and Source files, and i assume that it then updates the PDB sourcefile paths to reflect the source server setup.

If this is the case it does not work.

It that is not the expected behavior of Proget, then how do i manipulate the PDB to reflect the Proget source server, so the Source code is available for stepping.

nb. Proget claims that source and symbols are available for the package.

Thomas

Product: ProGet
Version: 2.2.13

What about it specifically doesn't work? Are the source files actually in the package? You shouldn't have to do anything with the .pdb files - as long as they're alongside the .dlls and the src files are in the /src directory, it should work.

For reference, here is the official NuGet guide to creating a symbol package: http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package

Just in case it helps you, I was having problems with this, and I finally realised the problem was that I wasn't including the PDB files in my release builds. So although a symbol package was created with the source files, because there was no PDB, ProGet assumed it was just a normal NuGet package.

So basically, double check you actually have PDBs in the lib\netXyz folder of your symbol package.

I'm having the exact same problem as OP.

I've got a fresh installation of ProGet with a single feed called Test with the following settings:

Feed Disk Path: C:\ProgramData\ProGet\Packages\Test
Symbol/Source Server enabled
Automatically strip PDB files disabled

I have a single .NET 4.0 class library package in the feed. The package uploaded was a *.symbol.nupkg file. The package contains a .dll and .pdb file in the lib folder and the source code is included.

Package contents

For some reason when I install TestLibrary1 package in another project, the source files and PDB are downloaded instead of just the assembly.

I've configured VS to use http://localhost:81/symbols/Test as my source/symbol server. I've unchecked "Enable Just My Code" and "Enable .NET Framework source stepping" and enabled "Enable source server support".

VS loads the PDB successfully, but it still can't find the source file for step-through debugging:

Output window prints this:
"SRCSRV: The module '...\Projects\ProgetTest\ProgetTest\bin\Debug\TestLibrary1.dll' does not contain
source server information."
Modules window says symbols were loaded for TestLibrary1.pdb

The "No Source Available" window shows the following debug info:

Looking for source using source server...

The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: ..\Projects\TestLibrary1\TestLibrary1\Class1.cs.

The debugger could not locate the source file '..\Projects\TestLibrary1\TestLibrary1\Class1.cs'.

Fiddler doesn't show any requests to ProGet to fetch TestLibrary1 symbols or source, only System.Data.pdb, Microsoft.VisualStudio.HostingProcess.Utilities.pdb, and others like that.

@Brett - What version of ProGet are you using?

Also, have you seen this thread: http://inedo.com/support/questions/2450

I deleted my test feed and package, cleared my symbol cache, and started over. Everything seems to be working now.

My test package PDB and source files are added to the symbol cache and the VS debugger successfully finds the source files.

tbl_5153

@Brett
I'm the original poster, and we still have issues with the Source server.
It worked for a while, and now we are having issues once more, but it is not consistent and therefor hard to track down.

Now that you say it works, i'm wondering if VS is simply using your local sources, here i'm assuming that the package is build from a project that is local on your machine.
As far as i remember the PDB contains information on the original filepath of the source, thus VS can actually find your local source.

This has been evident on several occasions in our teams, since we could alter the source we were stepping into and the source was then altered in the project from which it originated.

Now that you say it works, i'm wondering if VS is simply using your local sources, here i'm assuming that the package is build from a project that is local on your machine. As far as i remember the PDB contains information on the original filepath of the source, thus VS can actually find your local source.

I took that into account by deleting the local project from my machine after creating the package. My test package was correctly being unpacked into C:\Users\...\AppData\Local\Temp\SymbolCache\src\source-files\ and the source code used during debugging was a read-only copy located in that directory and not the original source code.

I can't really say what I did to fix it, other than clearing my symbol cache and making a new feed + package and ensuring the package contained the PDB and source files.

My limited understanding of how source/symbol servers work is that the server unwraps the PDB on the fly and modifies the absolute paths to the original source code (which could be on a build server or another developer's machine) to instead point to a local cache on your machine. Without this functionality PDB debugging would be impossible I think.

Product: Proget
Version: 3.4.2

I have the same problem as described by others here. I have configured the VS to "enable source server support" and disabled "enable just my code"

a) build a package using nuget pack -sym
b) verify that sources and pdb are included in the resulting package
b) create a new proget feed with "Automatically strip PDB files when downloading packages" unchecked
c) push the package to this feed
e) rename the source code tree used to build the above component
f) in visual studio 2013, configure the nuget source to "http://localhost:81/nuget/Test4"
g) change the debugging -> symbols paths, adding "http://localhost:81/symbols/Test4"
h) create a new project, add the nuget package as above
i) add a line of code that references a class in the referenced library
j) debug.

I notice the following:

In the output window I get:

SRCSRV: The module 'C:\Users...\libtest.dll' does not contain source server information.
In the main window I see:

Locating source for 'c:...\TestClass1.cs'. Checksum: MD5 {63 58 85 6 aa e0 74 1d 74 25 af f4 ff 87 27 4b}
The file 'c:...\TestClass1.cs' does not exist.
Looking in script documents for 'c:...\TestClass1.cs'...
Looking in the projects for 'c:...\TestClass1.cs'.
The file was not found in a project.
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src\vccorlib'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\mfc'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\src\atl'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include'...
Looking for source using source server...
The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: c:...\TestClass1.cs.
The debugger could not locate the source file 'c:...\TestClass1.cs'.
If I check the symbol cache directory, it's there, but nothing is in it.

I've tried this a number of times now and can't get past it. Any help would be appreciated!

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.