19

In Visual Studio 2015 and .NET Core development we could debug NuGet packages by retrieving the source code from a source (e.g. GitHub) to a local disk, adding the source path to the downloaded source code in global.json and reference the NuGet package in our project. This caused a reference to the projects in the downloaded source code to automatically be visible in the current solution and thus made it possible to easily debug (More about this functionality can be read about in this article).

Does anyone know how to do the same using Visual Studio 2017? Since the global.json is gone I can't find any solution for this.

Francisco d'Anconia
  • 2,436
  • 1
  • 19
  • 25
Rune G
  • 1,447
  • 2
  • 12
  • 26
  • 1
    Same way you do it for a normal .NET assembly (yay csproj). Right click the solution in the Solution Explorer window > Properties > Common Properties > Debug Source Files. Add the path where the source code is stored. – Hans Passant Mar 13 '17 at 18:05
  • Tried this, but it still doesn't give me the possibility to debug, the nuget packages doesn't have any pdb files, so it won't load ('dotnet.exe' (CoreCLR: clrhost): Loaded 'C:\Users\\.nuget\packages\microsoft.entityframeworkcore\1.1.1\lib\netstandard1.3\Microsoft.EntityFrameworkCore.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.). (e.g, try the Microsoft.EntityFrameworkCore package). And added the path to the src root folder as I did in the global.json file in 2015. – Rune G Mar 13 '17 at 22:15
  • This is really really really fustrating that there is no clear answer for this problem. Not good microsoft. It was all working very well with project.json and global.json until that ditched it all.... aagghhhhh – activebiz Apr 01 '17 at 06:50
  • I reported this as a feedback at visualstudio.com (https://developercommunity.visualstudio.com/content/problem/89455/debugging-nuget-packages-using-visual-studio-2017.html). Upvote it if you feel for it and keep track there. – Rune G Aug 07 '17 at 16:01
  • If there is ever an solution to this it would be great to update this post. – Spaceman Oct 27 '17 at 01:22
  • @spaceman go to the link above and upvote it – Rune G Nov 09 '17 at 07:29
  • @Spaceman - Ping, one solution – Rune G Jan 23 '18 at 18:51
  • see https://stackoverflow.com/a/50937658/379279 – xhafan Apr 20 '23 at 16:33

2 Answers2

2

I see this has become a popular question, however, MS is (as for the most time nowadays in Visual Studio) absent in requests that actually can improve their product.

There are some posts around out there on how to use the reference library from Microsoft, but this doesn't apply to all projects plus you will debug optimized release bits which is limiting in both watch and step capabilities. I also feel that this way to do it even slows down a slow Visual Studio even more. This way to do it is described in this post.

However, lately I have found a way to work around this issue. It isn't always stable, but what can be done is to add the related project to your project as a project reference.

But here are the steps I have done that mostly works:

  1. Clone the repository of the nuget package from github (or other source)
  2. Try your best to find which commit that the nuget package was built from (most projects references with either tags or branches, but don't expect this, it may be better to compare dates on the nuget package and commits).
  3. Follow the instructions from the project on how to build it, some is simply building in Visual Studio other may require more steps like using some build scripts in command prompt.
  4. Add a reference to the project in the solution, some times you'll also need to add the project that the project references to, but not always. Haven't found exactly the rules here yet. It seems that newer Visual Studio updates doesn't need this.
  5. Add a reference to the project in ALL projects that references the nuget package within your solution. Failure to do so may cause conflicts which the compiler tries it best (not good enough) to solve.

Build and debug, in your output window check that the assembly located in your project's output folder is used. If it is, just hit breakpoints in the referenced projects and you'll have full debug functionality.

It is a bit of trying and failing to make this work, but it does work eventually.

It is possible to create conditions on the project references to ensure that they isn't built in e.g. release builds, however, be aware that changing configuration requires that you reload your solution AFTER the change!

Rune G
  • 1,447
  • 2
  • 12
  • 26
  • Im using a similar solution via a powershell script that looks in into all proj files in the target solution for nug refs that i want to be proj refs search the new clone folder for that proj copy it over and update the ref. Its a super painful solution tho. – Spaceman Jan 25 '18 at 02:55
0

Here's the easiest way that I found that works repeatably:

  • Acquire the source code and build a nuget package locally. You'll need to increment to package version. Hopefully the author has provided a .nuspec to make building easier.

Create a local nuget source:

  • Place the .nuget file that you just created in C:\Nuget (for example)

  • In Visual Studio, select Tools / Options / Nuget Package Manager / Package Sources

  • Press the green (+) icon. Add the path to the local nuget package that you created above (C:\Nuget) and move the package source to the top of the list.

  • In your solution, for each project, remove the previous reference to the external nuget package and add the new nuget package from your local nuget source.

  • Start debugging and you should be able to step into the code for the nuget package.

I'm able to set a breakpoint in the source code from where I build the nuget package and have it break when I run the code.

All of the steps above are a little fidgity and you may need to play with it a few times to get it to work.

Francisco d'Anconia
  • 2,436
  • 1
  • 19
  • 25