次の方法で共有


Debugging through the .NET Core framework using VSCode (e.g. on Linux)

In my blog 'Debugging Through the .NET Core framework' I give specific instructions for setting Visual Studio up so that you can debug into the source code for the .NET Core Runtime.      Since Version 2.1 of the .NET Core runtime, it is also possible to do this using the 'Visual Studio Code'  editor.    Since Visual Studio code runs on Linux (as well as windows, or  MacOS), this is what you would be using if you were developing on non-windows platform.

Conceptually we are doing the same thing, but the exact details are a bit different, so I document them here.    They are mostly a transcription of VSCode doc on the subject.

Basically you have to sure you are running V2.1 of .NET Core or beyond, as well as V1.15 or beyond of the OmniSharp C# VSCode extension.

With those preliminaries out of the way, you basically need to update the '.vscode\launch.json' that VSCode set up in your project to describe how to launch your app and add these entries inside the 'configurations' array for the configuration that you use.

 "justMyCode": false,
"symbolOptions": {
"searchMicrosoftSymbolServer": true
},
"suppressJITOptimizations": true,
"env": {
"COMPlus_ZapDisable": "1"
}

The critical piece is turning off 'justMyCode'  This tells the debugger that you want to step into things outside your project.   However in order to do this it needs to find the symbols for code outside the project.  This is what the 'searchMicrosoftSymbolServer' does.    Note that this WILL cause alot of files to be downloaded from the symbol server THE FIRST time you debug something, but after your local caches has been populated it should be fast.

The last two entries improve the experience debugging through the code.   By default you are debugging the optimized code that was compiled by Microsoft and shipped with the .NET Core framework.   This means you don't tend to see local variables or even arguments of methods.   Sometimes this is OK, but sometimes it can be VERY frustrating.   Setting the 'COMPlus_ZapDisable' environment variable tells the runtime NOT  to use the precompiled code, and the 'suppressJITOptimizations' says when you do recompile it (Just in time) don't optimize it.  Together this makes the code unoptimized and thus you see all the local variables as you would like.   This DOES slow the code down a bit, but for debugger you probably don't care.