26

We have a lot of in-house libraries that we would like to share between projects inside the company. These are some of the requirements:

  • library sources are stored in repositories separated from end-projects
  • end-projects include libraries via NuGet
  • it must be possible to easily inspect the source code for any given libary while working on an end-project

Setting up our private NuGet repository isn't a problem, but managing sources is. We tried to expose the sources via source server and it kinda works, but not quite: VS downloads the sources while debugging external code, but not when you try to navigate to definition/implementation. Basically, you can only go to source code when debugging, which is not quite what we need.

So, the questions are:

  • what ways exist to provide access to source code of internal libraries without the need to having the code in the same repo/solution
  • is there a way to set up the Symbol server/NuGet feed combo so that VS uses the symbols for navigation, not just for debugging?

Using ReSharper/other add-ins is an option.

Brad Bruce
  • 231
  • 1
  • 6
Dyppl
  • 421
  • 4
  • 7
  • 3
    We found the use of Nuget for managing internal projects sub-optimal; we eventually ripped it out in favor of project and DLL references. I'd love to hear from someone who was able to make this work. – Robert Harvey Aug 01 '16 at 21:53
  • Have you also set up a symbol server for the pdb files that correspond to the dlls that are contained in your NuGet packages? – RubberDuck Aug 02 '16 at 01:02
  • 3
    We have the exact same setup at my current workplace. NuGet server (contains DLLs *without* PDBs) plus symbols server (contains DLLs, PDBs and sources). We also have the same issue (sources and PDBs retrieved only when debugging). @RobertHarvey: The NuGet Package Manager is a poor NuGet client. It doesn't differentiate between direct and transient dependencies and requires silly "consolidate" actions. We switched to [Paket](https://fsprojects.github.io/Paket/) and have never looked back since. It made package management sane and bearable, bordering on pleasant. – Allon Guralnek Aug 04 '16 at 18:26
  • I'm going through this right now myself. I'm leaning towards a Symbols Server for our internal NuGet server, but just started investigating it. I think we'll need a separate site that will hold documentation and links to our TFS repository for that project. This way you can browse the code while debugging, and browse the code through Team Foundation Server too. I don't know enough about this to post an answer, though. – Greg Burghardt Oct 14 '16 at 12:54
  • 2
    I have to ask - though I don't think this is an unreasonable requirement - why do you need to be able to look in the shared / common packages? Notionally at least these should be documented black boxes and the need to look inside should the exception rather than the norm. In any case they are available in your source repo and it should therefore be tolerably trivial to download the solution to inspect. I can see any number of reasons why this or parts of this might not be entirely the case, but its still worth asking. – Murph Oct 20 '16 at 13:01
  • 5
    @Murph - I'm not the OP, but in my experience documentation never captures the detail I want. Do I need to clean up this state or will the callee? What exactly is this escaping? How do these overloads differ? Do these entities support equality, and if so, based on what? What the approximate complexity of this call? The only *detailed* documentation worth having is the (clean) source, because there's always and commonly going to be things the documenter never considered but that *are* important to you. Worse, complex documentation inevitably contains errors and grows stale. – Eamon Nerbonne Feb 17 '17 at 14:37
  • @EamonNerbonne good answer - and in the general case I agree, however it is context dependent which is why its worth asking. It also has the potential to be a driver for change (as in _why_ is that the case and can we change it so that the necessity goes away) – Murph Feb 19 '17 at 09:46
  • Reusing libraries in this way naturally introduces a barrier. Nuget packages should be a bit like internal open source projects - you can dig out the source when you need it, but 95% of the time documentation is good enough. If you need to be able to regularly navigate to the source of a shared nuget package then maybe your documentation / encapsulation needs work, or it's potentially not the best choice to be a nuget package. – Justin Aug 05 '17 at 23:35

3 Answers3

1

What should work is simply checking out the source code for the NuGet package and opening the solution in a separate instance of Visual Studio.

Visual Studio has a neat trick of switching between code in open instances by working out what you have referenced. The first time this happened to me whilst I was debugging, was a revelation.

The main problem you face is making sure the checked out code for the dependent package represents the same version as your NuGet reference in the main project. Not a problem if you follow a policy of always building against the most recent version of your package.

Another benefit of this approach is that if the package needs to change, you can make the change there and then.

Stewart Ritchie
  • 159
  • 4
  • 3
    Can you provide some additional details on how one makes this to work? It doesn't work the way you described for me. Do you need to include PDBs in the package? Any additional tricks? – Dyppl Nov 04 '17 at 11:22
-1

Maybe you can use https://github.com/GitTools/GitLink. It adds a link in the pdb file pointing to the repository so Visual Studio will fetching source code from there - and then you just need to include the pdb file in your nuspec package and won't need a source server.

Jesper Balle
  • 1
-1

So it's not a perfect solution, but you mention that you could optionally use Resharper; with dotPeek and resharper you can navigate to the disassembly of the original code, it's what I use at work, where we have a similar setup to yours.

I find a combination of the Symbol Server you mentioned and browsing the disassembly is normally sufficient to figure out what's going on.

Hope that helps.

Edit: Having re-read your question I realise you specifically ask to be able to browse the source code, which this is not. Nonetheless hopefully it'll be useful to someone.

BaronVonDrew
  • 11