Go to source in a multi solution enviroment in Visual Studio 2019

Question

We have a scenario like this:

We have ~100 solutions containing 10 projects each. Each solution copies its artefacts (ie its 10 dlls) to a shared single folder like C:\code/assemblies . If I develop something for feature X, I'll open up SolutionX. The source for all solutions/projects is local in a single Monorepo C:\code .

During debugging, when the method/class/whatever is implemented in project Y, it opens the corresponding file (which is nice). So there must be information available how to get to the source.

But when developing, I cannot navigate to the implementation eg by using F12 ("go to definition") but just get the signatures gathered from meta data. I'd like to have the same experience like during debugging.

So right now I open up a Visual Studio Code, open the folder containing the sources and do a "search in files".

Any better ideas?

Nb Resharper is not an allowed option. Also doesn't play nice with Postsharp.

Nb I don't know if it is important but all except one solution start an external program (the shell), since all except one solution contain only dlls.

Answer 1

I have done similar in Old project.

You can use Symbol with Visual Studio 2019. Simple steps can be:

A. Generate Symbols for projects:

1. In Solution Explorer, select the project.

2. Select the Properties icon (or press Alt+Enter).

3. In the side pane, choose Build .

4. In the Configuration list, choose Debug or Release .

5. Select the Advanced button.

6. In the Debugging information list, choose Full, Pdb-only, or Portable.

Refer for more information:

Set debug and release configurations in Visual Studio

Publish symbols for debugging

B. Use Symbol in Visual Studio:

1. In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).

2. Under Symbol file (.pdb) locations,

   • To use the Microsoft Symbol Servers or NuGet.org Symbol Server, select the checkbox.

   • To add a new symbol server location,

   Select the + symbol in the toolbar. Type the URL (http), network share, or local path of the symbol server or symbol location in the text field. Statement completion helps you find the correct format. Tools - Options - Debugging - Symbols page

For more Details refer:

Configure symbol locations and loading options

Answer 2

I think you should analyze project dependencies (for example with https://www.ndepend.com/docs/visual-studio-dependency-graph ) and cluster your projects in less Solutions

Answer 3

Edit: I am editing this answer based on your comment. I think you are looking for two use cases

1. Peek into the source code of referenced binaries
2. Navigate to the source and then edit them in place

To achieve option (1)

In Visual Studio 2019, use the built in decompiler to help you with navigating to code outside of the solution. This is an experimental feature as of May 2020. By default this is disabled and you should enable it. Once enabled the F12 navigation will decompile and allow you to peek into the source code.

On the other side, the more you relax the compilation the better the decompilation. Meaning, you can turn off optimisations (if any). This doesn't have to do anything with symbol generation options.

If you are using visual studio 2017 (or) less, the same can be achieved by Telerik Just Decompile plugin (free). Check the feature View decompiled code in tabs

To Achieve option (2):

You should reference source files rather than binaries, because you won't get the natural in-place edit with referencing binaries. There are always going to be caveats irrespective of the solution you choose. Referencing source can be done using the "Add as link" feature in Visual studio, where the source code belong to one solution and can be referenced as link (something like windows shortcuts) in all the other solutions. ( https://andrewlock.net/including-linked-files-from-outside-the-project-directory-in-asp-net-core/ ). If you are referencing source, you need to remove the binary references.

And you also have to decide from an architectural standpoint on how this changes the way people develop and commit code. The point of referencing binaries is to make sure they are not edited for convenience, but that depends on the nature of the development team purely.

Conclusion

From a best practices standpoint, you either have to reference binaries and don't allow them to be edited (or) you allow source references and edit in place. But that depends purely on what you want to achieve.