We Keep Coding

I'm not able to debug .NET Core source code

Yes, I know that this question arises from time to time, I have searched for answer on internet, but nothing seems to work right. So I prepared I detailed explanation, accompanied by screenshots, on what I tried to do to be able to follow code execution throught .NET Core source code and what was the result.
I'm using Visual Studio Community 16.8.3, and have created a .NET Core 3.1 web app from template. I changed the code in Startup class to make it crash.
These are my debug settings (I have no idea weather .NET Framework source stepping has any significance for .NET Core projects):
So lets run and hit an exception:
Here I'll choose just to decomplie the source code (there's a link for it on the previous image), to see if this works:
OK, but I just see the code, can't examine variable and object values. Let's rerun and see if I can get the code by clicking on the symbol server when the exception hits:
It complains, so let's enable source servers.
Lets run it again, and hit the exception.
Now it complains on some kind of exclusion (see symbol status column):
I load all the symbold manually:
Here I rerun the app, with all the symbols loaded, but when the exception hits I still can't F11 into the .NET Core source:
What am I missing to be able to step throught the .NET Core source code?

Did you enable Source Link? I was able to step into the .NET Core 3.1 source code after doing the following:
Uncheck "Enable Just My Code" and check "Enable Source Link support" in Tools -> Options -> Debugging -> General
Activate the symbol servers in Tools -> Options -> Debugging -> Symbols
I got this information from Improving Debug-time Productivity with Source Link on Microsoft Devblogs.

The exception says that public method Configure is missing in Startup class. The application did not start properly and that is why debugging does not work.

Source files mismatch when stepping into .NET Framework code

Motivation
I'm trying to track down an exception thrown by .NET Framework when opening connection to Access mdb database file. I'm not opening the database connection directly but rather use one of DevExpress Xpo facilities (XpoDefault.GetDataLayer(...) to be precise) which internally attempts to create connection to provided mdb database file. That attempt fails somewhere deep in .NET Framework code and exception is thrown.
Exception has System.Data.OleDb.OleDbException type and is very vague about the problem source. Message says "Unspecified error". ErrorCode is -2147467259 (NativeCode is 0). There is to little information to find out why database connection cannot be created. I thought that maybe going deeper into .NET Framework code would reveal something important about the failure.
Problem
Source files mismatch when stepping into .NET Framework internals. Inconsistent execution flow.
Description
My application is targeting .NET Framework 4.6.1 x86 platform and built in Debug (Release does not change anything). Visual Studio Enterprise 2019 v16.6.3 is the IDE I work with. Of course I've read all I could about debugging into .NET Framework first but it did not help to solve my problem.
What I have done so far? I have successfully download DevExpres PDBs and sources. No problem with that - I can follow execution down into DevExpress internals (which IMHO confirms that overall debugging setup is rather correct). It also seems that .NET Framework PDBs are correctly loaded from Microsoft servers during debugging. I think that Visual Studio Debugging settings are also fine (as far as I'm aware).
All goes well until I need to step into OleDbConnection.cs file which gives the following message:
The problem is that I have all .NET sources available from https://referencesource.microsoft.com. All (including updates) from version 4.5.1 up to latest 4.8.
No matter which one I choose - I'm always getting same message about not matching source file version. When I ignore the message and decide to use the source file anyway, it shortly turns out that inconsistency is real. Instead of tracking the source code execution I'm stepping over comments or execution flow simply does not make sense and clearly the presented source code is not in sync with what is going on.
Ok, that's it. I could not get any farther. Am I doing something wrong? Where to look for .NET Framework sources which would match the executing modules and allow to discover origins of the exception I'm getting?
Update #tgolisch
Code which gives an exception:
Session Session;
ReflectionDictionary reflectionDictionary;
string connectionString;
...
Session = new Session(XpoDefault.GetDataLayer(connectionString, reflectionDictionary, AutoCreateOption.SchemaOnly));
Connection string used in XpoDefault.GetDataLayer(...) call:
"Provider=Microsoft.Jet.OLEDB.4.0;Password=;User ID=Admin;Data Source=C:\\Svn\\trunk\\Apps\\bin\\Debug\\DbFile.mdb;Mode=Share Deny None;"
XopDefault.GetDataLayer(...) is the call which fails and throws exception.
Update #Perry Qian-MSFT
I did exactly what you suggested with no success. There was no improvement at all. However, I have made a fair progress after disabling optimizations of system assemblies as described here. With optimization turned off, tracking of .NET Framework internals becomes feasible. No more random jumping or stepping over comment lines.
However, it is not a full success yet, because I'm still getting messages about mismatch between executing modules and the source code file versions.
I have also noticed that even though my app has .NET Framework 4.6.1 as a target it still uses version 4.8 of system modules during execution:
That suggests I should use .NET Framework 4.8 sources when stepping into framework internals. But wait - I have tried all sources I could get with the same mismatch problem.
What can also be seen is that there is more than one version of system assemblies being run with the app - 4.8.4110.0 and 4.8.3761.0, which suggests that different sources might have been used to build them.
Yet still, no matter which sources I take there is always a message about source mismatch at some point.
Considering that assembly optimization problem has been resolved, which framework sources should I use now to have them in sync with running modules?

Source files mismatch when stepping into .NET Framework code
Please reconnect your DB Access database to refresh your database in case there are some build errors in the db layer.
Besides, please follow these suggestions to troubleshoot your strange issue:
1) Tools-->Import and Export Settings-->Reset all settings-->..General to reset all debugging settings.
2) then, close VS, delete .vs hidden folder under solution folder, bin and obj folder.

Error CS7038 (failed to emit module) only in Edit and Continue

I'm debugging a .NET 4.0 application in Visual Studio 2015. My application builds and runs fine, but when I try to edit and continue while running under the debugger, regardless of what changes I make or where I make them in my main project, I get a dialog that says:
Edits were made which cannot be compiled. Execution cannot continue
until the compiler errors are fixed.
As an example of the sort of change I'm talking about, I've tried adding this line in various methods:
Console.WriteLine("foo");
When I look in Visual Studio's Error List pane, I see only one error, CS7038, with the description "Failed to emit module '<my app name>'." No filename, line number, or character is given. There are no squiggly red underlines in my code. If I stop the running application, build with the changes, and run again, everything builds and runs just fine. So there seems to be some discrepancy between what the build-time compiler and the edit-and-continue compiler consider acceptable.
Does anyone know of a way to get more information about why the compile fails in Edit and Continue mode? I read something about attaching to and debugging the VBCSCompiler process, so I tried that, but even with all exception types set to break when thrown, the attached VS never broke.
I'm not sharing any code because this isn't a question about my code but rather about strategies for finding out what the Edit and Continue compiler thinks is wrong, and for all I know the source of the compiler error could be anywhere in my entire project.
Edit:
As mentioned in the comments, I was able to attach a debugger to Visual Studio and break when an exception was thrown upon clicking "Continue" after editing code. The exception was a System.NotSupportedException with the following message: "Changing the version of an assembly reference is not allowed during debugging". It listed the name of the assembly in question, which was a small VB.Net project used by my application, which is mostly in C#. I'm trying to build up an MCVE to submit to Microsoft, but currently I'm unable to reproduce the problem in a smaller solution with just one VB and one C# project.
Edit 2:
I've found a workaround and self-answered the question in case anyone else ever encounters this weird problem, but I'm reserving the "Answered" check mark for anyone who can explain what's going on (why the compiler thinks the version number of the referenced project has changed during the edit).

I found a workaround for the problem, but I don't fully understand what was going on. In the VB.NET project whose assembly version the Edit and Continue compiler said was changing, there was a file called "AssemblyInfo.vb". That file contained the following line:
<Assembly: AssemblyVersion("3.0.*")>
The assembly version can also be set in the Project Properties, via the "Assembly Information" button in the Application tab:
When I removed the AssemblyVersion line from AssemblyInfo.vb, my Edit and Continue problem went away. At first I thought this was because the fields in the Assembly Information window were saved to a different file from AssemblyInfo.vb and there was some conflict between the two, but now I see that the Assembly Information window is just a handy way to edit AssemblyInfo.vb: if I delete the line in AssemblyInfo.vb, it gets cleared in the Assembly Information window.
After some more experimentation, it appears that the asterisk in the version number is the culprit. If I fully specify the assembly version, my Edit and Continue problem goes away. And the referenced project has to be a VB.NET project. I tried the same setup with a C# project, and I could Edit and Continue just fine.
This appears to be very much an edge case, and I'll submit a bug report to Microsoft, but in the meantime I'd love to know what is actually going on with the compiler--why it's getting two different assembly versions of an assembly that really shouldn't need to be recompiled during the debugging.... If you have a good explanation for what's happening, please add it as an answer.
Edit: here's the bug report I filed.

This happened with me in a .net 4.8 app with Visual Studio 2019.
I have a mix vb and cs projects, here the problem appears when a vbproj references a csproj that uses the wildcast operator '*' to specify the version of the assembly.
As commented above by #Wai-Ha-Hee, the wildcast uses the current time, I belive when VS rebuild the application to apply the edits you have made, the version of the assembly changes causing the error.
In assemblyInfo file (of the project present in error) Change:
[assembly: AssemblyVersion("1.0.*")]
To:
[assembly: AssemblyVersion("1.0.0.0")]
It Solved for me.
An important thing to say is the use of wildcast '*' make the assembly non-deterministic, it means each build produces a different assembly. This has been considered bad practice because build the source code in the same conditions generates different assemblies.
In Visual Studio 2019:
New csproj/vbproj with non-sdk style projects file are generated with:
<Deterministic>true</Deterministic>
And new csproj/vbproj with Sdk style projects file omits this line but assumes deterministic as default too.
I recommend considerate other ways to version the assembly.
More about Deterministic:
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
https://reproducible-builds.org/

One of my C# projects in a mixed solution was .NET Framework 2.0 (while others - both C# and VB.NET - were .NET Framework 4). After I changed it to .NET Framework 4 it began to work.

Hiding code from a DLL while debugging

I've created a DLL with a Class Library Project with some classes. While adding this DLL as a reference in another projects and debugging, when going step by step or when the class returns an Exception the code from the class is shown.
How can I hide this? I want the exception to be shown on the class instruction, not inside and allowing to see al the code. And when debugging by steps, I want to do the methods without steping inside the code of the method.
Just like if you step through str.Split(), for example. You don't see the code and all the steps. You just see the error on that line or jumps to the next one.
For example:
Dim myObj As New myClass.SomeObj()
myObj.MyMethod()
I do not want the code inside MyMethod to be shown.

Add on the specified method a DebuggerStepThrough attribute to prevent step into. If an exception occures, the debugger breaks at the method call, not inside the method. See MSDN

The behavior you describe is a convenience. It allows the caller to see exactly what is going wrong by looking at the details of the code he's trying to consume. Microsoft even supports this for the .NET Framework source, and it's rather useful in my opinion. I'm not really sure why you'd want to disable it. You can always just use F10 (Step Over) instead of F11 (Step Into) when debugging so that the DLL's code remains available in case you ever need it.
But if you are sure that you don't want to be able to step into any code from the DLL, you need to make sure that the debug symbols are not available to the client application. Visual Studio generates these symbols in the form of a PDB file, which contains the location of the source files and mappings between the generated code and the source lines.
Contrary to some of the other answers, the generation of debug symbols is unrelated to whether the code is optimized (e.g., a "Release" build). I've written about this before in the context of why you might want symbols for an optimized build, but the point is that these are two orthogonal settings. You can turn on optimization and turn off symbol generation, and vice versa. Suffice it to say that I strongly recommend generating debug symbols for all builds.
You can disable the generation of debug symbols in the project's properties (it's hidden under the "Advanced..." button), or you can just move the PDB files to ensure that the client application cannot locate them when debugging. By default, a build places them into the same directory as the binary output, so that when you add a reference to the DLL, Visual Studio finds them easily. If you move either the symbols or the binaries, it won't be able to find them. (The debugger also searches the symbol path, but your symbols probably won't end up there.)

Why does my C# debugger skip breakpoints?

My C# debugger is not working properly. It skips break points and line of codes sometimes. I have checked the configuration manager. I have even tried adding my projects to new solution files. Can someone please help me?

My debugging checklist:
Make sure your attaching to the process using the correct code type - if your process has both unmanaged and managed code then dont rely on "auto" to work for you, explicitly state what sort of code your trying to debug
Goto the modules window (Debug -> Windows -> Modules, you may need to enable it in the "Customize..." menu
Check to make sure that the assembly your trying to debug has been loaded, and that symbols have been loaded - if they haven't been loaded then right click on that module and select "load symbols"
Open your code file and place your breakpoint - if it appears with the little warning symbol then look and see what it says,
You might need to goto "tools -> options - > debugging -> general" and untick "Enable Just My Code (Managed Only)"
You might also want to uncheck "Require source files to exactly match the original version", if you think your sources might be slightly out (beware however, as this can lead to you debugging with completely the wrong sources, which can be very confusing)
On certain cases you might find that your module doesn't get loaded at the point where you attach your debugger (for example if you have some sort of plug in archetecutre, and plugin assemblies are only loaded when you first use them). In these cases all you can do is try and make sure everything is prepared ready for when the module is loaded.

Make sure optimizations are disabled (this is the defaut for the Debug configuration, but they are enabled in Release configuration). Compiler optimizations can mess with the debugger...

Are you sure that it compiled correctly? It sounds to me like you're debugging against a previous version, which can happen if the build fails (perhaps a code bug, perhaps the files are readonly).

If entire methods are being skipped, look at the source and see if the System.Diagnostics.DebuggerStepThroughAttribute attribute is present.
Despite the name, it PREVENTS the debugger from stepping through the method.

This worked for me in VS 2017, Go to Tools > Options then under the Options Window go to the Debugging section. Enable - "Enable .NET Framework source stepping"

This sounds like your source code is out of sync with the PDB files. The easiest solution is to clean the solution (which deletes all your dlls from the bin folder). Recompile, and then try stepping through again.
If it still fails, try closing the solution and deleting the "obj" folders. And then try again.
And also check you are compiling in debug mode - something I've done often ("why isn't it stepping through?!")
not getting break point

If at least sometimes the break point is hit it means that all the settings are most probably OK.
The missing hits may be caused by some side-effects, for example: property evaluation by the debugger (at least VS skips the breakpoints during the property evaluation for debugger) or some spying tools (but these are usually catch by debugger).
If you think this may be the case, turn off the spying tools and disable the property evaluation by the debugger.
This may be sometimes not enough, for example: If your property returns a collection, displaying e.g. a Count() will evaluate the property - so remove also all references of property from the watch windows, etc.

Disabling "Project Properties/Build/Optimize code" worked for me.

#Justin's answer above was super helpful. I would add one thing to the list.
Check to make sure you're running in debug and that your debug preferences have "Optimize code" unchecked. See below:

Also make sure that the code you're trying to debug is running in the same process as the main executable. I just wasted a half hour figuring that one out - the breakpoint wasn't hitting because the code of interest had been spun up in a child process instead of being called directly (the program in question has two different modes of operation).

If you're getting this kind of error:
The current .NET SDK does not support targeting .NET Core 2.1. Either target .NET Core 2.0 or lower, or use a version of the .NET SDK that supports .NET Core 2.1. DCR_Parser
Right click on the project in solution explorer and click on Properties. Under the Application tab go to Target framework .NET Core 2.0. And save.