Run and debug .NET projects of executable types

Create a run configuration for .NET project

1. Open the Run/Debug Configuration dialog in one of the following ways:

   • Select Run | Edit Configurations from the main menu.

   • With the Navigation bar visible (View | Appearance | Navigation Bar), choose Edit Configurations from the run/debug configuration selector.

   • Press Alt+Shift+F10 and then press 0.

2. In the Run/Debug Configuration dialog, click Add New Configuration Alt+Insert, choose the .NET Project configuration type, and specify a name that will help you identify this configuration in the future.

3. Optionally, adjust the common settings of the configuration and configure before launch tasks.

4. Choose a startup project of executable type.

5. In Target framework, select a .NET framework version that will be used to run this configuration.

6. The path to the executable file of the selected target project is calculated automatically, but you can change it if needed.

7. Optionally, specify program arguments that will be passed to the executable when the configuration is started. Multiple arguments should be separated with whitespaces.

   For some project types (for example, Web Application), JetBrains Rider will fill this field automatically so that the target project could be started correctly.

8. Optionally, specify a custom working directory, otherwise the directory of the target executable will be used.

9. Optionally, specify custom environment variables for the target executable in the following format:

   envVar1=value1;envVar2=value2

10. Optionally, specify .NET runtime arguments. Multiple arguments should be separated with whitespaces.

    Both .NET and Mono support setting custom runtime arguments when launching an application. For example, Mono supports many runtime arguments to customize how your application is run. You can select the garbage collector to be used (--gc=boehm or --gc=sgen), on macOS you can select the runtime architecture to be used (--arch=32 or --arch=64), and more.

11. Optionally, use the Runtime selector to choose one of the runtimes available on your machine.

    If you are working on Windows, you can check how your application works with the Mono runtime. JetBrains Rider will use the Mono executable specified on the Build, Execution, Deployment | Toolset and Build page of JetBrains Rider settings Ctrl+Alt+S.

    To debug with Mono runtime, you need:

    • Mono 4.2+

    • Portable PDB in your projects — <debugtype>portable</debugtype> in the .csproj file, or alternatively, generate mdb with pdb2mdb.

12. Optionally, choose the Terminal mode. By default, Automatic is selected, which means that JetBrains Rider determines the optimal terminal output mode based on project and IDE settings. If necesseary, you can choose the terminal output mode manually:

    • Automatic — Rider chooses the most suitable mode based on the run configuration and the executable type.

      • Typically uses PTY (pseudo terminal) for console-style programs to provide an interactive terminal experience (the process “thinks” it runs in a real terminal; isatty() is true; terminal control sequences may work).

      • Typically uses standard stream redirection for GUI programs (for example, auto-detected on Windows when linked with /SUBSYSTEM:WINDOWS), where no terminal is expected.

      • Note: Defaults cannot avoid all edge cases (especially on Windows), so switching modes can help when output/interaction is broken.

    • Enable pseudoterminal — Runs the process inside a pseudo terminal (PTY / ConPTY on Windows).

      • Best for programs that expect a real terminal: interactive prompts, TUI apps, shells, readline-style input, etc.

      • Enables “full terminal experience”: isatty() returns true and terminal control sequences (cursor movement, clears, etc.) are intended to work.

      • Known limitation: terminal emulation can be unreliable in some scenarios (for example, incorrect behavior in certain programs, especially on Windows).

    • Redirect standard streams — Captures stdin/stdout/stderr via redirection rather than running in a terminal.

      • Provides basic text output collection in the Rider Run window.

      • Most terminal-specific behavior is not available: many apps will treat output as “not a terminal” (isatty() is false), so interactive features and terminal control sequences typically won’t work.

      • Color output is often reduced/disabled by programs in this mode (commonly “no color” unless the program supports forced color in redirected output).

    • Redirect standard streams with ANSI codes — Redirects streams like the previous option, but allows ANSI escape sequences to pass through for colored/styled output.

      • Useful for programs that can emit ANSI color codes even when output is redirected (or when forced by configuration/environment).

      • Still not a real terminal: interactive terminal behavior generally remains unavailable (isatty() is false), and terminal control sequences beyond simple styling may not behave as expected.

      • This mode is aimed at improving readability (colors) without switching to full PTY mode.

    • External Console — Runs the process outside Rider Terminal window. It is a recommended workaround for certain programs (notably some GUI programs) that break when their streams are redirected, e.g., cases like GUIConsole.WPF / ConPTY demo scenarios.

    • Disable — Does not attach Rider’s console/terminal handling to the run configuration output. This may be useful for GUI applications (where terminal output redirection is not desired) or when any form of Rider-mediated output causes issues.

13. By default, the output of .NET and Mono applications is shown in the Run or Debug window. You can select Use external console to show the output in an external window.

    Note that this checkbox does not affect classic .NET application types (for example, .NET Console Application) — their output is always shown in an external window.

14. When you run the configuration in the Debug mode, JetBrains Rider attaches its debugger only to the original .NET process. If you want to debug child and grandchild processes spawned by the original process, select Attach to child .NET processes.

    Note that this option will only work with .NET 8 and later.

15. Click Apply to save the configuration.