Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with Debugging into a nuget package with symbols #7100

Closed
JCookVF opened this issue Jul 9, 2018 · 1 comment
Closed

Issue with Debugging into a nuget package with symbols #7100

JCookVF opened this issue Jul 9, 2018 · 1 comment
Labels
Area:Symbols Resolution:Duplicate This issue appears to be a Duplicate of another issue

Comments

@JCookVF
Copy link

JCookVF commented Jul 9, 2018

Details about Problem

NuGet product used (NuGet.exe):

NuGet version (4.6.2.5055):

VS version (VS Professional 2015 v: 14.0.25420.01 Update 3):

OS version ( Microsoft Windows 10 Pro, 10.0.17134 Build 17134)

Detailed repro steps so we can see the same problem

When I follow the steps to create a debug-able nuget package it works great on my computer. I have created a simple nuget package (along with it's symbols) that is hosted on a fileshare here at work. On the computer that created the package, I can import the nuget package into another project and debug into the nuget package just fine. However, when another developer here imports the nuget package in the exact same way on their computer the debugging does not work.

This is the case even when I've had them set up a reference to the fileshare in their Visual Studios Tools>Options>Debugging>Symbols.

Steps that I followed:

  1. Create a C# project with a simple method to be called from another project.
  2. Build the project in debug mode.
  3. Package that project with ( nuget.exe pack "DebugTest.csproj" –symbols )
  4. After successful packaging, move the two new files, (.nupkg & symbols.nupkg) into the fileshare at work.
  5. Go to new project and import the package into the solution from the fileshare via the nuget package manager. (This includes adding a reference to the fileshare in the nuget package manager)
  6. Import and insert a reference to the method from the nuget package in the new project.
  7. Add a reference to the fileshare where the nuget symbols exist via Visual Studios Tools>Options>Debugging>Symbols
  8. Place a breakpoint on the call to the nuget package and build/deploy the solution
  9. Step into the nuget package.

As mentioned above, from step 9 if I am on the computer where the nuget package was made I can step into the nuget package just fine. However, if another developer follows the same process from step 5 on a different computer, it does not work.

Other suggested things

I have done a little research on this and I believe that this may be due to the .pdb files having absolute file paths. (i.e. the pdb in the nuget.symbols package is pointing at the path in my local files, not the fileshare). This is may be why it isn't working on other developer's computers even though they have access to the nuget packages and symbols from the network fileshare.

It has also been suggested to me that when the two files are made from the packaging process (.nupkg & .symbols.nupkg) that I should rename the symbols package to just .nupkg and put only that on the fileshare. This still follows the same issue, in that it works on my local computer but not on other developers' computers.

Verbose Logs

nuget.exe pack "DebugTest.csproj" –symbols

@PatoBeltran
Copy link

Hey @JCookVF thanks for opening this issue. This scenario in fact is of our the current pain points we are tackling, we already have an issue tracking this work (#6104). We are actively working on fixing this and you should be hearing of this experience getting solved soon, please feel free to follow up and continue the conversation in the linked issue. I will close this issue as a duplicate of that one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:Symbols Resolution:Duplicate This issue appears to be a Duplicate of another issue
Projects
None yet
Development

No branches or pull requests

2 participants