Develop Reference

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

We have a scenario like this:
We have ~100 solutions containing 10 projects each.
Each solution copies its artefacts (i.e. 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 e.g. 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?
N.b. Resharper is not an allowed option. Also doesn't play nice with Postsharp.
N.b. 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.

I have done similar in Old project.
You can use Symbol with Visual Studio 2019. Simple steps can be:
A. Generate Symbols for projects :
In Solution Explorer, select the project.
Select the Properties icon (or press Alt+Enter).
In the side pane, choose Build.
In the Configuration list, choose Debug or Release.
Select the Advanced button.
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:
In Visual Studio, open Tools > Options > Debugging > Symbols (or Debug > Options > Symbols).
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

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

Edit : I am editing this answer based on your comment. I think you are looking for two use cases
Peek into the source code of referenced binaries
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.

"No symbol has been loaded for this document" when debug asp.net mvc framework source code

I am trying to debug asp.net mvc source code. Here are the steps I took:
I set up a bare-bone asp.net mvc application (version 5.2.4) by using the template offered by Visual Studio 2017.
I downloaded asp.net mvc source code from offcial github, and according to this, MvcHandler will be hit in the code path so I put a breakpoint in its processRequest() method.
I follow the instruction from the microsoft reference web (there is a link on the main page) about how to set up VS and I use "https://referencesource.microsoft.com" as symbol server.
During debugging, I also make sure "System.Web.Mvc.dll" is loaded (dll for MvcHandler).
I think I get both source code and pdb, but I still get error: "no symbol has been loaded for this document". I want to know what other steps I can take to solve this.
Some other posts I read:
(1) can't debug asp.net MVC
(2) same error message

There should be no need for you to download the MVC 5 source code, the whole point of symbols and source servers is to fetch those source files for you as needed while debugging.
I use "https://referencesource.microsoft.com" as symbol server
That's likely your problem - Reference Source is only for the .NET Framework. In order to get MVC 5 symbols and source files, you need to add a different symbol server, such as SymbolSource - see http://www.symbolsource.org/Public/Wiki/Using.
You should also be aware that a lot of the information around debugging with symbols is outdated. In particular, in VS 2017 and later, there is a new option under Tools > Options > Debugging > General called "Use managed compatibility mode", which should be unchecked.
If all else fails, since you already have the MVC source on your machine, simply point your solution at - either by removing the MVC DLL references and including and referencing the relevant projects in your solution, or by replacing the MVC DLL references with references to your own locally-compiled DLLs. This is a lot more pain and effort than using symbol servers, but it's also 100% reliable.
For troubleshooting purposes, the Modules window (Debug > Windows > Modules when debugging) is invaluable; it will show you what DLLs were loaded by your project, what PDBs were loaded for them and where from, and if a PDB wasn't loaded it will tell you why. You can also manually force a PDB to be loaded via right-clicking a particular DLL and browsing to its location.
See also: Debugging Asp.net MVC 5.2.3 source code

I solved my problem.
Instead of using Asp.net Mvc 5.2.4, I downloaded the latest Mvc package here: https://dotnet.myget.org/feed/aspnetwebstack-dev/package/nuget/Microsoft.AspNet.Mvc
and that does the trick for me (Everything else I did stay the same).
So if one version doesn't work for you, try a different version!

First time exception - System.pdb not loaded

I use VS2017 and I get the following when I hit F5
It happens for certain projects only, even if I disabled the Symbols support under VS options. Although in the past, for the same projects it used not to throw even with Symbol support enabled.
So, since I assumed this must be some kind of cached VS setting project specific, I deleted bin, obj, .vs , SymbolSource folders but the same.
If I enable Just My Code it does not throw, however this is not what I want since I cannot debug assemblies which I already have the symbols.
As far as I know even if Symbols Support is enabled it shouldn't throw if there isn't a related Symbol Server declared in VS Options.
This behavior is not specific only to System.dll but happens even if I attach to external processes which I do not have symbols, meaning that filtering with the Load Only Specified Module VS option again is not what I am looking for.
So, does anybody have an idea on how to avoid such annoying exceptions while allowing to utilize Symbol Support for other assemblies which I have configured.

It means that you want to step in to the
.net Framework source code:
http://referencesource.microsoft.com/setup.html
http://referencesource.microsoft.com/indexedpdbs.txt
Actually we also reported this issue to product team for VS 2017 before:
Stepping into .NET Source Still Doesn't Work
If you really want to avoid it, I suggest you disable settings like "Enable .NET framework source stepping" under TOOLS->Options->Debugging.
To debug .NET framework source code,we need to:
Disable just my code
Disable step over properties and operators
Disable require source files to exactly match the original version
Enable .NET framework source stepping
Enable source server support
So just use the contrary settings as above options, debug it again.
In addition, please enable the symbols server under TOOLS->Options->Debugging->Symbols Server, and enable the exception settings window, view the detailed exception messages, maybe you have to resolve the Exception firstly or get any helpful information from it.

Try to uncheck the debug hosting service.

None of the above worked for me because I was using external DLL which didn't have the PDB file with it. I found that when I removed all the breakpoints.
Go to Debug menu > Windows > Exception Settings (or press ctrl + alt + E)
Now check Common Language Runtime Exceptions or click Restore default (Refer screenshot):
So when it throws exception and you don't see it, it want to use the PDB file to store the stack trace but it didn't find it.

I had to check Enable native code debugging under Debug tab in project properties to get rid of this issue (Refer screenshot)

How do I debug .NET 4.6 framework source code in Visual Studio 2017?

Here's what I've tried:
Made a new Console App (.NET Framework) in Visual Studio 2017.
Added the following code:
static void Main(string[] args)
{
new Dictionary<int, int>().TryGetValue(3, out int x); //I want to step into TryGetValue() (this is just an example)
}
Configured the settings listed here:
https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/
Confirmed symbols are loaded in the Modules window:
mscorlib.dll Symbols loaded. 4.6.1586.0 built by: NETFXREL2
Tried: "Step Into (F11)"
Tried: "Step into Specific" | "System.Collections.Generic.Dictionary.TryGetValue"
Both just step over the line.
I've tried configuring VS using the details here: http://www.symbolsource.org/Public/Home/VisualStudio
Same result, the debugger steps over the line.
I've looked at the answer here: https://stackoverflow.com/a/12432029/297451
But this version doesn't seem to be a security update, and a search for "site:support.microsoft.com/kb 4.6.1586.0" yields nothing.
What am I doing wrong?

Here is the answer, thanks to Hans Passant. Note that this solution raises additional questions.
Ensure https://referencesource.microsoft.com/ contains the exact version you're debugging.
How? Reference source specifies ".NET Framework 4.6.2" but a module version is something like: "4.6.1586.0"
You may need to uninstall security updates as explained here: How do you enable "Enable .NET Framework source stepping"?
Configure Visual Studio as specified here:
https://referencesource.microsoft.com/setup.html
Untick "Enable Just My Code"
Tick "Enable .NET Framework source stepping" (this should have been the only step needed)
Tick "Enable source server support"
Untick "Require source files to exactly match the original version"
Confirm symbols are loaded in the Modules window, with source indexing included.
How can you tell if source indexing is included? The modules window doesn't specify if a PDB has stripped source information.
Microsoft could make this process a lot more robust by giving helpful error messages instead of silently failing.

Use the Symbol Server feature in JetBrains dotPeek. Worked like a charm for me after struggling to get the standard functionality to work:
Run dotPeek and go to Tools > Options... > Symbol Server.
Ensure that "All assemblies" is selected and copy the local symbol server URL to the clipboard. Start the dotPeek symbol server by clicking it in the Tools menu.
In Visual Studio, go to Tools > Options... > Debugging > Symbols and add the dotPeek server URL to the list. Move the dotPeek symbol server as high up the list as possible, and uncheck all other symbol servers in the list (in particular, the "Microsoft Symbol Servers" and "NuGet.org Symbol Server" must not be selected).
Start debugging - when you attempt to step into Framework source code, you will see dotPeek doing some work decompiling the assembly for you, and then you will be into its source.
If this doesn't work, it's probably because Visual Studio has previously downloaded the "wrong" symbols for the assembly in question from Microsoft/NuGet, and is using them instead of asking dotPeek. To check this, start debugging and find the relevant assembly in the modules list (Debug > Windows > Modules) - delete the PDB file at the path displayed under "Symbol File" for that assembly, then restart debugging, and dotPeek should kick into action.

How to debug into my nuget package deployed from TeamCity?

I have put a library that my team uses into a nuget package that is deployed from TeamCity into a network folder. I cannot debug into this code though! SymbolSource is one solution I have read about but I would much rather find some way to have access to the .pdb/source files directly from TeamCity. Does anyone know how to do this?
Edit. When I check 'Include Symbols and Source' in the Nuget Pack build step, TeamCity creates a .Symbol.nupkg in addition to the .nupkg file in the network folder. The .Symbol.nupkg contains the src and the .pdb file.
Edit. I unchecked 'Include Symbols and Source' on TeamCity and added the following to my nuspec file:
<files>
<file src="..\MyLibrary\bin\release\MyLibrary.dll" target="lib\net40" />
<file src="..\MyLibrary\bin\release\MyLibrary.pdb" target="lib\net40" />
<file src="..\MyLibrary\*.cs" target="src" />
<file src="..\MyLibrary\**\*.cs" target="src" />
</files>
This added the dll, the pdb, and the source files for my library in the nuget package and didn't generate a .Symbols file which I think is only needed for symbol servers.

Traditional method
Put the pdb in the NuGet package alongside the dll.
Add the source code to the Debug Source Files for the solution that references the package.
This means you'll be able to step through code and view exceptions, but you might have to find a file on disk and open it before you can set a breakpoint. Obviously you need to be careful that the source is at the right revision.
More detail on step
If you're currently packaging without a Nuspec, you'll need to create a Nuspec, then add the pdb to the list of files in the lib folder "NuGet spec" may be a useful command for generating the initial spec as defined in NuGet docs. Then ensure the Team City Nuget Pack step is referencing your new nuspec.
More detail on step 2
When you have a solution open, right click on Solution, select Properties...Common Properties...Debug Source Files, and add the root source directory for the relevant binary reference. Or see MSDN.
Note, you can't open the solution properties while debugging.
Still not hitting breakpoints?
Try disabling this from Tools->Options:
Modern way for public or private repos
To ensure the exact version of the source is available, embed it at build time.
From Visual Studio 2017 15.5+ you can add the EmbedAllSources property:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<EmbedAllSources>true</EmbedAllSources>
Modern way for public repos
To keep your nuget and library size small, you can use the sourcelink package.
It generates a pdb that directs the debugger to the correct version of the file from your VCS provider (e.g. GitHub, BitBucket).

The latest version of dotPeek (free!) can act as a symbol server and generate pdb files on the fly. This has allowed me to debug into the dlls that are served via teamcity.
Download it here:
http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program/
Instructions on how to set it up here.
https://web.archive.org/web/20160220163146/http://confluence.jetbrains.com/display/NETCOM/dotPeek+Symbol+Server+and+PDB+Generation

You could of course set-up & configure your own symbol server, but it's probably easiest to...
download and install Inedo's ProGet
enable symbol serving on the target feed
publish packages from TeamCity to the ProGet feed
use ProGet as your primary feed source (as it can aggregate multiple feeds including nuget.org)
All of this can be done with the free edition of ProGet.
disclaimer -- my day job is at Inedo

In your .nuspec (directly under <package>):
<files>
<file src="bin\$configuration$\$id$.pdb" target="lib\net451\" />
</files>
(change net451 to the platform you're compiling for)

If you have the source code for the package, then the foolproof (but possibly laborious) method is:
Add the source code for the package to your solution (right click Solution -> Add Existing Project)
Go through all of your projects in the solution and remove the NuGet reference to the library (i.e. open the References folder under each project and delete the reference to the package.) Then, add a reference to the NuGet package project in your solution. (i.e. Right click References, add Reference, choose Projects and tick the box for the project)
I had to do it this way when I the method I wanted to debug inside the NuGet package was called by the framework and not by my code, thus I couldn't step into it. (In my case, the method was an ASP.NET DelegatingHandler).
Once you're done you'll want to undo all your changes via source control so that the NuGet package is referenced correctly.

I've found a super simple way to do this, which I have blogged about here:
https://mattfrear.com/2017/11/29/speed-up-development-in-a-nuget-package-centric-solution/
This only works if you're using the new .NET Core style .csproj with <PackageReference> (on either .NET Core or .NET Framework).
This again assumes you have access to the source code of the NuGet package.
Build and compile the NuGet package on your local machine
Copy the .dll you've just compiled into your local NuGet packages feed folder (On my machine, this is C:\Users\matt\.nuget\packages\), overwriting the existing NuGet package .dll.
That's it! You should be able to step into the package while debugging. No messing around with .pdbs or source servers. This has greatly sped up my development cycle.

Since this question was originally posted, Jetbrains have written an entire blog post on how to accomplish this. The steps can be summarised as:
Install Debugging Tools for Windows on the agents.
Install & Enable the Symbol Server plugin.
Add Symbol Files Indexer build feature to your build configurations.
Ensure PDB files are output as an artefact.
Configure Visual Studio to use TeamCity as source server.
If you are using Nuget Package build steps, you can check 'Include Symbols and Source' to output a .symbol.nupkg which contains the PDBs. Depending on whether the Symbol Files Indexer is smart enough to look inside this file or not, you may need to change the file extension for things to work.
The full details are given here:
https://blog.jetbrains.com/teamcity/2015/02/setting-up-teamcity-as-symbol-and-source-server/

This is what I have found to work, but all the steps are probably not required...
Note: this doesn't allow you to debug both, only either the nuget
package or the solution in which it is installed.
Run Visual Studio as Administrator
Open and Start the host application (the one in which you installed the Nuget package) without debugging (Ctrl + F5)
In the Nuget package solution, ensure that Tools > Options > Debugging > General > "Require source files to exactly match the original version" is NOT checked.
Ensure that "Enable just my code" is NOT checked
Add a new folder in Tools > Options > Debugging > Symbols pointing to the source directory of the Nuget package. (You literally enter the folder path , see image below)
Click Debug > Attach to Process...
Find iisexpress (there may be multiple, it won't do any harm attaching to all)

If your code is in a public Git repository, or, at least in your network, is accessible without authentication, then GitLink would be an option:
https://github.com/GitTools/GitLink
GitLink makes symbol servers obsolete by changing the PDB to point to the Git server. But, as said before, this makes it necessary for the Git repository to be public - until now there's no "proper" way to authenticate when accessing a private repository.

Microsoft has now integrated the SourceLink NuGet package at https://github.com/dotnet/sourcelink/ which allows source code to be downloaded on demand while debugging if the publisher of the NuGet package sets it up.