Reputation: 3487
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:
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:
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.
Upvotes: 20
Views: 13717
Reputation: 214
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
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 symbolsNuget 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.
Upvotes: 8
Reputation: 143
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.
Upvotes: 10
Reputation: 481
Some fundamentals:
Next:
Upvotes: 3