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.

8
  • 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 1 '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 2 '16 at 1: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 and have never looked back since. It made package management sane and bearable, bordering on pleasant. – Allon Guralnek Aug 4 '16 at 18:26
  • 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
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.

1
  • 2
    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 4 '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.

1
  • 1
    Does it work outside of debugging though? It doesn't look like it does. – Dyppl Aug 22 '16 at 18:43
-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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.