$(String[] args) in /home/ubuntu/HelloWorld/Program.cs:line 8 ``` Two problems appeared: 1. The first name of the list, Alice, is skipped, followed by a `Hello, Bob`, then `Hello, Charlie`. 2. An unhandled exception of type `System.ArgumentOutOfRangeException` happens. According to the error message, we are trying to access an index that does not exist in the collection. Let’s debug. #### Setting up the debugger To debug a .NET application with Visual Studio Code, we need to create a launch profile. VS Code can create one automatically by clicking the Run and Debug icon, then the Run and Debug button, and selecting the .NET 5+ and .NET Core item from the menu that pops up.  With a launch profile created, go back to the Run and Debug section and click the little Play icon to start debugging the application. You will see that the exception is thrown on line 8, during the `Console.WriteLine` call.  By analyzing the Variables window, we see that the `names` variable has three items, but our index variable is already at 3. In .NET, arrays are indexed starting at 0, which means that the current index is one unit larger than the collection size. That explains the `ArgumentOutOfRangeException` being thrown.  The issue is that we are incrementing the index variable *before* accessing the names collection. Since the index variable is first assigned to 0, the first increment brings it to 1, making the program greet names starting from the second one – this is a classic [off-by-one error](https://en.wikipedia.org/wiki/Off-by-one_error). We fix this by moving `index++` one line down. Running the program again shows no errors:  #### Stepping over code Another great use of debuggers is the ability to step through code line by line. This is possible by setting breakpoints in the code. A breakpoint indicates to the debugger that, when running the program, it should pause execution at that specific line. This is especially useful when you, as the developer, want to understand the behavior of your code at one specific point. To set a breakpoint in Visual Studio Code, hover the mouse over the blank space to the left of the line numbers and click the line you want to set the breakpoint in. A red dot should appear indicating that a breakpoint is now set. Let’s go ahead and set a breakpoint on line 6:  Now, running the debugger should pause the execution of the program whenever it hits that specific line of code. You can analyze current variable values in the Variables window, see the call stack of the program at that specific line in the Call Stack window, and so on.  Clicking the Step Over icon, or pressing `F10`, should also let you execute the code line by line and watch how the program behaves in “slow motion”. For example, let’s step over the `Console.WriteLine` instruction, which should print `Hello, Alice` to the output console.  The index variable holds the value 0 at that specific point in time. Stepping over the variable increment instruction on line 7 should now bring `index` to 1.  To continue execution as usual, click the Continue button, or `F5`, and the program should now execute until it hits the next breakpoint. As we’ve set one inside the `while` loop, it stops again at the next iteration. To remove the breakpoint, clicking the red dot again, then click Continue to let the program resume and finish execution. #### Stepping into code Another feature of debuggers is the ability to step into functions as they are called. As an example, let’s create a function called `SayHello`, which prints a greeting for whichever name is passed as a parameter. Then, instead of calling `Console.WriteLine` from within the `while` loop, we call `SayHello`. ```csharp var names = new List { "Alice", "Bob", "Charlie" }; var index = 0; while (index < names.Count) { SayHello(names[index]); index++; } void SayHello(string name) { Console.WriteLine($"Hello, {name}"); } ``` Setting a breakpoint on line 6 should allow us to pause the execution right before calling the `SayHello` function.  Now, instead of stepping **over** this line, we step **into** it by clicking Step Into, or `F11`, which should allow us to go into the `SayHello` function and step over its implementation.  #### Stepping into .NET code When debugging, stepping into functions within your own code is straightforward, as the debugger has direct access to the source. However, stepping into functions from external libraries or .NET itself requires debug symbols, specifically [PDB files](https://documentation.ubuntu.com/ubuntu-for-developers/explanation/debugging-with-dotnet.md#pdb-files). This is the case if you want to step into `Console.WriteLine` itself, for example. Clicking Step Into when the debugger hits that line simply steps over it, as the debugger does not have the necessary symbols for the library that provides that function. However, if you install .NET from the Ubuntu archive packages, you can also install matching [.NET debug symbols packages](https://documentation.ubuntu.com/ubuntu-for-developers/explanation/debugging-with-dotnet.md#dotnet-debug-symbols-packages) that contain PDB files for the .NET SDK, Runtime, and ASP.NET Core Runtime. With these packages installed, debuggers are able to step into functions defined within .NET itself. Let’s set a breakpoint at `Console.WriteLine` on line 12. Make sure to disable Just My Code in your debug launcher; otherwise, the debugger would not step into framework code. To do that, add `"justMyCode": false` to your `launch.json` profile:  Alternatively, you can also disable Just My Code globally in the VS Code Settings. Look for the `csharp.debug.justMyCode` option and uncheck it.  Now, run the debugger:  If we step **into** that function, or `F11`, we go into the `Concat` function implementation, which is responsible for joining our `Hello, ` string with the `name` variable.  Let’s go ahead and step out of this function, since we want to look into the implementation of `Console.WriteLine` instead. Click Step Out, or `Shift+F11`, and the debugger takes us back to `Console.WriteLine` again – stepping out means “execute the rest of this function and go back to where its value is returned”. Now, Step Into it again, and the debugger should take us right to the implementation of the `WriteLine` function itself. You can keep stepping into the many functions that make up `Console.WriteLine` to better understand how it works internally.  ### Debugging with NetCoreDbg The Samsung .NET debugger (NetCoreDbg) is an open-source managed code debugger that implements GDB/MI and VSCode Debug Adapter Protocol in a unified framework, allowing the debugging of .NET applications under the .NET runtime as well as facilitating debugging from the command line (such as in GDB). If you use a VS Code-based editor, such as VS Codium, you cannot use the Microsoft .NET Core Debugger (VsDbg) due to its [license](https://aka.ms/vscode-dotnet-dbglicense), which states that “.NET Debugging is supported only in Microsoft versions of VS Code”. In that scenario, you will need to use another debugger, like NetCoreDbg. We use VS Codium for the purposes of this tutorial, but the steps should translate very similarly to any other VS Code-based code editor. 1. Install VS Codium: `dev@ubuntu:~$ ``sudo snap install --classic codium` 1. Open VS Codium and install a C# language support extension from the Extensions store. For this tutorial, we use [`dotnetdev-kr-custom.csharp`](https://open-vsx.org/vscode/item?itemName=dotnetdev-kr-custom.csharp).  1. Open the Hello World project created in [Creating a .NET project](#creating-dotnet-project) with VS Codium: `dev@ubuntu:~$ ``codium HelloWorld` #### Setting up the debugger The NetCoreDbg debugger is available as a snap in the Snap Store. To install it, run: `dev@ubuntu:~$ ``sudo snap install --classic netcoredbg` We need to create a `launch.json` file inside the `.vscode` directory, which is a file used to configure debugging in a VS Code-based editor. In your project’s root directory, run: `dev@ubuntu:~/HelloWorld$ ``mkdir .vscode && touch .vscode/launch.json` Open the `launch.json` file and fill it in with the following content: ```json { "version": "0.2.0", "configurations": [ { "name": "netcoredbg", "type": "coreclr", "request": "launch", "program": "${workspaceFolder}/bin/Debug/net10.0/HelloWorld.dll", "args": [], "cwd": "${workspaceFolder}", "pipeTransport": { "pipeCwd": "${workspaceFolder}", "pipeProgram": "sh", "pipeArgs": ["-c"], "debuggerPath": "netcoredbg", "debuggerArgs": ["--interpreter=vscode"], "quoteArgs": true }, "env": { "DOTNET_ENVIRONMENT": "Development" } } ] } ``` Important parts of this configuration: - `"program"`: The path to the compiled .NET application to debug. Adjust the path according to your .NET version and project name. - `"pipeTransport"`: Configures how to launch the NetCoreDbg debugger. - `"debuggerPath"`: The command to run the NetCoreDbg debugger. We are using `netcoredbg`, which is the command provided by the snap package installed earlier. - `"debuggerArgs"`: The arguments to pass to the NetCoreDbg debugger. We are using the `--interpreter=vscode` argument to put the debugger into VS Code Debugger mode. To ensure you are always debugging the latest version of your application, build the project before starting a debugging session. Let’s create a build task. Create a new file called `tasks.json` inside the `.vscode` directory: `dev@ubuntu:~/HelloWorld$ ``touch .vscode/tasks.json` Open the `tasks.json` file and fill it in with the following content: ```json { "version": "2.0.0", "tasks": [ { "label": "build", "command": "dotnet", "type": "process", "args": [ "build", "${workspaceFolder}/HelloWorld.csproj" ] } ] } ``` Now, add `preLaunchTask` to the `launch.json` file. Update the configuration to include the following line: ```diff "cwd": "${workspaceFolder}", + "preLaunchTask": "build", "pipeTransport": { ``` #### Running the Application Replace the content of `Program.cs` with the following code block: ```csharp var names = new List { "Alice", "Bob", "Charlie" }; var index = 0; while (index < names.Count) { index++; Console.WriteLine($"Hello, {names[index]}"); } ``` This is the same code block used in [Debugging with VS Code](#debugging-with-vscode). The goal of this program is to build a list of names – Alice, Bob, and Charlie – then greet each one with “Hello” within the `while` loop. However, running this code shows that it is not working as expected: ```default Hello, Bob Hello, Charlie Unhandled exception. System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index') at System.Collections.Generic.List`1.get_Item(Int32 index) at Program.

$(String[] args) in /home/ubuntu/HelloWorld/Program.cs:line 8 ``` Two problems appeared: 1. The first name of the list, Alice, is skipped, followed by a `Hello, Bob`, then `Hello, Charlie`. 2. An unhandled exception of type `System.ArgumentOutOfRangeException` happens. According to the error message, we are trying to access an index that does not exist in the collection. Let’s debug. #### Debugging the Application Go to the Run and Debug section in VS Codium and click the Play icon to start debugging the application.  Notice an exception is thrown on line 7, during the `Console.WriteLine` call. dotnet run  We can fix the code by moving `index++` to the correct place, after the `Console.WriteLine` call, as explained in [Debugging with VS Code](#debugging-with-vscode) and use the Codium interface to debug the application, set breakpoints, and inspect variables, with NetCoreDbg just like we did with the VS Code debugger. Refer to [Stepping over code](#stepping-over-code) and [Stepping into code](#stepping-into-code) for more details on how to use the debugger features. To learn more about NetCoreDbg and its features, visit the [official GitHub repository](https://github.com/samsung/netcoredbg).