I've published some private/internal libraries as NuGet packages, using the symbols option. The packages and symbols are hosted on an internal network share. How can I step into these packages when debugging?
When I step to code from these packages, Visual Studio displays a "No Source Available" / "No Symbols Found" page. Clicking the "Load Symbols" only allows pdb files, not symbol packages.
These packages are not suitable for publishing on NuGet Gallery/SymbolSource.
What is the command that you used to generate the packages with the symbols? I tried to do the same exact thing nuget.exe pack -Prop Configuration=Release Framework.csproj -Symbols
This creates two files: Framework.nupkg and Framework.symbols.nupkg. I put these files on a network share, used them from another project and debugging worked fine.
Have you tried putting the *.nupkg and *.symbols.nupkg files on a local disk instead of a network share?
There are a couple options; one is to set-up & configure your own symbol server.
You could also download Inedo's ProGet, enable symbol serving on the target feed, and then publish your packages to ProGet. All of this can be done with the free edition of ProGet.
disclaimer -- my day job is at Inedo
There is also now a tool called GitLink (https://github.com/GitTools/GitLink) which can insert into the symbol file links to versioned GIT files of your source.
You can set up your own symbolsource server internally using those network shares.
You can find a step-by-step tutorial on my blog.
It basically comes down to create an empty MVC application and run
Install-Package SymbolSource.Server.Basic
From there on you need to set up the hosting infrastructure and configure Visual Studio and build agents.
The way we do it (and works):
- Generate "*.symbols.nupkg"
- Deploy symbol package to SymbolSource server (private)
- Configure IDE
- Add required Library to project using NuGet (from our SymbolSource server)
- Debug!
Links that can be useful:
I found that it doesn't work at all. NuGet package references are closed and cannot be used in the debugger. What I did instead was deleting the assembly reference from the project and instead added a reference to a Debug build of the DLL directly by path.
Then to make the debugger halt somewhere in that code, I inserted the call System.Diagnostics.Debugger.Break();
in that code. When running, the debugger will halt at that line, which is basically a code-defined breakpoint. This will open the correct source file and jump to that line automatically.
Open the library project in a second VS instance and move around the Break
calls as necessary and rebuild the library. When done, remove those calls from the library code and restore the original reference (may need to reinstall the NuGet package).