JetBrains Rider 2025.3 Help

Run and debug .NET executables without source code

If you need to launch a compiled .NET executable without source code, you need to configure the startup properties of the target executable in a run configuration. Once the configuration is created, you can launch it with the debugger attached Shift+F9 or without debugging Shift+F10. In case of debugging, the executable will be automatically decompiled.

Another scenario is using a compiled .NET executable as a part of testing or debugging your project of a non-executable type, for example, a class library. In this case, you need to launch the created configuration together with another configuration that executes your code as multiple targets.

Create a run configuration for .NET executable

  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 Add New Configuration Alt+Insert, choose the .NET Executable 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. Specify the path to the target executable.

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

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

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

    envVar1=value1;envVar2=value2
  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. Click Apply to save the configuration.

JetBrains Rider run configuration: .NET Executable
29 January 2025