title: How to package and deploy a NuGet package with symbols and source code so that debugger can use THAT source code?
body: <p>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#.</p>
  
  <p>I used this command to create the nuget package:</p>
  
  <pre><code>nuget pack MyProject.csproj -symbols -Properties "Configuration=Debug" -suffix debug
  </code></pre>
  
  <p>Which creates, as I expect, two nuget package file, namely:</p>
  
  <ul>
  <li>MyProject.1.0.0-debug.symbols.nupkg</li>
  <li>MyProject.1.0.0-debug.nupkg</li>
  </ul>
  
  <p>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.</p>
  
  <p>Given the duplication, I rename the file <code>MyProject.1.0.0-debug.symbols.nupkg</code> as <code>MyProject.1.0.0-debug.nupkg</code>, which overwrites one of the files, no big deal there.  I now have a conventionally named package with PDB and source files in it.</p>
  
  <p>I deploy this to an internal file share feed with:</p>
  
  <pre><code>nuget add MyProject.1.0.0-debug.nupkg \\InternalShare\FeedFolder
  </code></pre>
  
  <p>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.</p>
  
  <p>So far so good.</p>
  
  <p>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.</p>
  
  <p>OK.  So now I recreate my simple console app on a <em>separate</em> 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.</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>Various versions of things:</p>
  
  <ul>
  <li>Visual Studio:  Professional 2017 15.9.11</li>
  <li>NuGet Package Manager installed in VS: 4.6.0</li>
  <li>CLI NuGet version:  4.8.1.5435</li>
  <li>Targetted .NET Framework for my sample code:  4.6.1</li>
  </ul>
  
  <p>What is my mistake?</p>
  
  <p>Many thanks in advance.</p>
  
  <p>================== ADDED INFO 4/17/2019, 3:30pm Pacific =======================</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Still, it would be great not to have to jump through hoops like that, so I would still appreciate any further insights.</p>