Debugging with Visual Studio

Just as in Fire and Water, Elements provides sophisticated sophisticated debugging support for all supported target platforms and all Elements languages in the Visual Studio IDE.

For developing .NET projects, Elements will use the built-in Managed debugger provided by Visual Studio; for all other Platforms, Elements integrates its own debug engines (the same used in Fire and Water) with the IDE.

Depending on the target platform, the debugged applications will run locally, on a remote computer (connected to via CrossBox over SSH), or a physical device connected locally (Android) or on a remote Mac (iOS Device or Apple TV).

Please refer to the Working w/ Devices topic for more details on what options are supported, and how to select the appropriate device.

Launching

After selecting the target machine or device, the remainder of the debugging process is the same, for all platforms. You have several options to launch or deploy your application, available via the "Project" menu and corresponding keyboard shortcuts

  • "Start" – the default option, selecting this will build your application, deploy it (where necessary) to the target device, and then run it in the debugger. Most of the remainder of this topic will be focused on this option. (F5)
  • "Start without Debugging" – selecting this will run your project, but without the debugger attached. You application will run as it would in production mode, without the overhead of the debugger, but also without its benefits. (Ctrl+F5)

There are three optional phases that might need to happen before debugging can start:

  1. Building (if your project has changed since it was last built)
  2. Uploading (when using a remote computer) and/or
  3. Deploying (when using a device).

The IDE is smart about not repeating these preparational phases unnecessarily, for example skipping a rebuild or re-deployment if your application code has not changed between runs.

The IDE also will smartly decide which projects to build as part of the run, avoiding to build projects (even if Enabled) that do not factor into the current project.

Debugging

Once a debug session is active and running, you can use the debugger to control it, including the standard debugging capabilities provided by the Visual Studio IDE.

Please refer to the Visual Studio debugger documentation provided b y Microsoft, for more details.

Note that different than Fire and Water, Console applications run from Visual Studio will not emit their output to a debug console in the IDE, but launch in a separate Command Prompt window, same as if they were double-clicked from File Explorer. This means that once the application terminates, the window will disappear.

You might want to add a call to readLn() at the end of your Entry Point to prevent the window from closing.

Further Topics

  • Startup Arguments
  • Environment Variables

See Also

and