17

I have created a very simple NuGet package from a .net framework visual studio Class Library project, where the class library source is in C#.

I used this command to create the nuget package:

nuget pack MyProject.csproj -symbols -Properties "Configuration=Debug" -suffix debug

Which creates, as I expect, two nuget package file, namely:

  • MyProject.1.0.0-debug.symbols.nupkg
  • MyProject.1.0.0-debug.nupkg

These packages are basically identical other than that the one with "symbols" includes the pdb files in the lib hierarchy and source files in the src folder.

Given the duplication, I rename the file MyProject.1.0.0-debug.symbols.nupkg as MyProject.1.0.0-debug.nupkg, which overwrites one of the files, no big deal there. I now have a conventionally named package with PDB and source files in it.

I deploy this to an internal file share feed with:

nuget add MyProject.1.0.0-debug.nupkg \\InternalShare\FeedFolder

In an entirely different project, and a different solution, I now consume that NuGet package in Visual Studio with the NuGet Package Manager. All works great. And the code works fine too, in my case I made a simple console app that uses a couple of classes in the package and I have demonstrated that it uses them correctly and without incident.

So far so good.

Now I set a breakpoint in the consuming code, and attempt to step into the source to debug the package. It seems to work OK, but actually, it isn't going into the source that was distributed with the package. It actually steps into the ORIGINAL source from the creation of the package, in a completely different and unrelated folder hierarchy on my machine.

OK. So now I recreate my simple console app on a separate computer that does not have the ORIGINAL source. And on that separate computer, which is on the internal network and hence has access to the file share, I consume the NuGet package and again, everything compiles and works fine.

When I try to step into the package source code in the visual studio debugger, however, it simply doesn't work. The debugger can't find the source code even though it is right there in the package folder. (The debugger offers to disassemble the code -- not so helpful).

This seems like it should be a common use case and desire for including symbols and source code in a nuget package, so I must be doing something silly such that the debugger can't find the source.

Various versions of things:

  • Visual Studio: Professional 2017 15.9.11
  • NuGet Package Manager installed in VS: 4.6.0
  • CLI NuGet version: 4.8.1.5435
  • Targetted .NET Framework for my sample code: 4.6.1

What is my mistake?

Many thanks in advance.

================== ADDED INFO 4/17/2019, 3:30pm Pacific =======================

This isn't quite as bad as I thought. When I try to go into the code and says it can't find it, I am given the opportunity to browse to the code, so I can browse to the package (assuming I know where it is!) and set the debugger loose and everything works fine. The nice thing is that Visual Studio seems to remember where I browsed to and knows to look there next time. Not sure of that mechanism.

AND.... If I go to my original computer (with the actual package source on it) if I change that initial source, like I am getting ready for the next package, the debugger (of course) realizes that the source has changed, and likewise prompts me to look for the proper source elsewhere.

Still, it would be great not to have to jump through hoops like that, so I would still appreciate any further insights.

Stephan G
  • 3,289
  • 4
  • 30
  • 49
  • I don't understand why you're trying to do this with a Nuget package. Couldn't you just clone the source repo into your working project? – alans Apr 17 '19 at 23:12
  • Sounds like you need symbol server functionality. If you can't publish your packages to an external feed (nuget.org) there are on premise solutions such as proget which are free to use (to a point). If you use git for your source control, source link might be able to help as well – pinkfloydx33 Apr 18 '19 at 08:56
  • I think the documents in karann's answer have described it in details. Something like a .snupkg if you want use nuget as source control. And the hoops you meet is hard to avoid if you use the way you mentioned above.(The debug engine will always try to search the original path and you have to tell it where to find it) Also, I think another choice is using source link to get the user a better debugging experience. – LoLance Apr 18 '19 at 09:17
  • In answer to @alans -- packaging seems to solve an internal need for continued access to versioned libraries. – Stephan G Apr 18 '19 at 14:47

3 Answers3

6

Back in Feb'2019 it was working. Few things which are not mentioned here and I added to csproj file are 

<DebugSymbols>true</DebugSymbols>
<EmbedAllSources>true</EmbedAllSources>
<DebugType>portable</DebugType>

I packaged with nuget and command used is:

nuget pack mynuget.nuspec -Symbols -SymbolPackageFormat snupkg

I was using VS 15.9.4 and nuget 4.9.3 at that time With this I could successfully debug nuget from network path . Not sure what changed in recent releases, its not working now.

user3397876
  • 103
  • 1
  • 5
3

Some fundamentals:

  • the debugger needs PDBs to enable debugging
  • a symbol package should contain PDBs (it is not merely a package with a different extension)
  • this symbol package should be published to a symbol repository that Visual Studio debugger can request symbols from

Next:

  1. See this doc for creating and publishing symbols package to nuget.org (.snupkg)
  2. Then, see this doc for configuring visual studio to for using NuGet.org as a symbol source (use this value when adding a symbol server https://symbols.nuget.org/download/symbols)
karann - MSFT
  • 481
  • 2
  • 11
  • I appreciate the answer, but it doesn't really answer my question. The package I am publishing (internally) includes both PDB files and source files. And when that package is consumed (again internally) if you navigate down through the packages file hierarchy on the consuming machine, you can see that the source and PDB files are there. Nuget is being used to pack up the nuget package. It seems it could ?easily? ensure that the PDB files in the package point relatively to the source files also packaged. Are you saying that doesn't happen? And I wonder why? – Stephan G Apr 18 '19 at 14:46
  • let's say you project generates myLib.dll and the associated pdb i.e. myLib.pdb and myLib.xml. Now if you place all 3 files in the same folder , the VS debugger will just pick it up. – karann - MSFT Apr 18 '19 at 18:58
  • so your package should look like this lib/net45/ – karann - MSFT Apr 18 '19 at 20:12
  • Thanks @karann. This now begs the question as to why NuGet, when it does the default packaging with -Symbols doesn't place those files in the correct spot? Is there a good reason for this discrepancy? (I realize I can tailor a .nuspec file for each project, but it is so nice not to have to.....) - FYI if I don't answer further comments immediately, I will be AWOL for a couple of days - back Monday. – Stephan G Apr 18 '19 at 22:19
  • @stephanG that's because NuGet does make the assumption that you want to ship the pdb with the package and bloat the package size unnecessarily. – karann - MSFT Apr 19 '19 at 20:09
  • A pity it makes that assumption! I'm using it internally and not worried about bloat.... – Stephan G Apr 22 '19 at 20:27
  • here is a woraround, put the following in a property group in the project file and that will make sure that the package includes the pdb $(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb – karann - MSFT Apr 25 '19 at 00:23
  • also check out source linking - https://github.com/dotnet/sourcelink/blob/master/README.md – karann - MSFT Apr 25 '19 at 00:34
0

I had a similar problem - wanted to (internally, throughout the company) export a nuget library complete with sources and the option to debug the code.

I tried all the permutations with

  • nuget pack with symbols
  • dotnet pack with sources & symbols
  • the old X.symbol.nupkg vs. the new X.snupkg

None of them worked as expected. Either the source was decompiled instead of the original; there would be no IntelliSense documentation; symbols weren't found; or they were found in the original nuget lib source destination so it only worked on my DEV machine and even that only until the original source was changed.

In the end, what worked for me was very simple :) csproj PropertyGroup with

  • <GenerateDocumentationFile>True</GenerateDocumentationFile> for IntelliSense documentation
  • <EmbedAllSources>true</EmbedAllSources> for sharing sources
  • <DebugType>Embedded</DebugType> for sharing debugging symbols

Nuget packing and pushing to a local network drive was also trivial:

  • dotnet pack -c Release -o .
  • dotnet nuget push .\<package_name>.nupkg --source <network_location>

Hope it helps anybody else.

berserker
  • 104
  • 5