Debug Properties

The properties you specify on the Debug page of the project properties apply to the selected configuration.

Each project template comes with a specific set of debug properties which are most relevant for the type of application it produces. This topic lists all of the debug properties available in the Visual COBOL projects. The ones available in a specific project template are depend on the type of application.

Profile: The debug profile stores a specific set of properties which specify how to start debugging the application. You can specify various details such as what to run (such as an executable, or an .int file, or a browser), whether to launch the application on a local or a remote machine, and how the debugger should attach (such as start a process or wait for an attachment).; A project can have multiple debug profiles which you can create with the New button.

Debug properties for native and .NET COBOL projects
Debug properties for Docker environments
Debug properties for native applications that require Enterprise Server to run

Debug properties for native COBOL and .NET COBOL projects

Launch:

Project: Specifies that the project is to be debugged by launching its output.
For projects that compile to multiple output files (.exe, .int or .gnt), you can specify which output file should be launched. You can only choose a file generated by the build in the directory specified in the Output field. Your choice is saved in the project properties.

Note: This setting does not apply to .NET COBOL class library projects that build to multiple .dll files. For these project types, you must specify a different start action.
Executable: The path to a file to be debugged. You can specify a path relative to the project directory.
This setting is typically used when your application is a library.

The following setting is only available for native COBOL projects:

Wait for debuggable attachment

The debugger waits for the program to start in a separate process before attempting to attach to it. Check this if you need to manually launch your process. You can set the following options:

Wait for any program - waits for and then attaches to the next COBOL program that calls CBL_DEBUGBREAK, or is launched with the COBSW environment variable set to +A.
Wait for directory - waits for and then attaches to the next COBOL program that is launched with its working directory set to either the folder specified in Working Directory, or a subfolder of it. If no working directory is specified then the project output path is used.
Wait for ID - waits for and then attaches to the next COBOL program which calls CBL_DEBUG_START with the identifier you specify in the ID field as an argument. You set the identifier in the source code - see CBL_DEBUG_START.

Launch Browser

Starts debugging by opening a web page.

The following start options are available:

Application Arguments: Program arguments to be passed.
Working Directory: The directory from which the program is launched.
Note: If Launch is set to Wait for debuggable attachment, then the path you specify in this field is used with the Wait for directory option.
Use remote machine: Check this to enable remote debugging. Specify the remote machine by entering its name over the network or its IPv4 or IPv6 address in the adjacent field..
Port: Specify the port number that is used by the cobdebugremote or cobdebugremote64 process.

Debug options:

The following properties apply to native COBOL projects only:

Enable multiprocess debugging: If the process you debug starts a new process using the CBL_EXEC_RUN_UNIT call, this setting allows the new process to be debugged in a separate instance of Visual Studio.
Return to waiting state when debugging: Check this to enable debugging of CGI programs when invoking them multiple times.

The following properties apply to .NET COBOL projects only:

Enable SQL Server debugging: Enables the Microsoft SQL debugger.
Enable mixed mode debugging: Check this to enable debugging of C/C++ code alongside .NET code.
Redirect standard output: Value of true or false, to determine whether or not standard output (such as System.Console.WriteLine) should be redirected to the debugger's output window. For Console projects, this is initially set to False, and for Windows projects it is initially set to true.
Note: This feature does not work for 64-bit applications and on 64-bit machines it is supported only by a x86 platform type.
Disable Windows authentication for remote debugging: Check this if you want to avoid having to provide credentials when connecting to the remote debugger. You need to ensure that the remote debugger is also configured to run without Windows Authentication. This can be useful in scenarios where it is not possible to set up the required credentials.
Warning: Enabling this option in the remote debugger makes your remote machine accessible to other users on the network.

Debug profiles for Docker environments

Project (Docker): Choose this profile to debug the project output within a Docker container. When you start debugging, Visual Studio will start the Docker container, launch the project output inside the container, and then debug it.
Executable (Docker): Enables you to specify the path to the executable that you want to launch when debugging a Docker container. When you start debugging, it will start up the Docker container, launch the specified executable inside the container, and then debug it.

Debug properties for native applications that require Enterprise Server to run

Specify whether to launch a Web service or a core dump file:

Web Service

Client IP: Leave this field empty to enable debugging from any IP address. Specify an IP address to allow debugging only from it.
Service Name: Specify the address of the web service to debug. Enter the address and any specific operation that is part of the web service in the following format - http://namespace/ServiceName#OperationName

Core Dump

Specify the name and the path to the core dump file to use for debugging your application.

Note: The controls displayed on the properties page are determined by the type of project you are working on. As a result, some of the controls described here might be missing from your properties page or be unavailable for selection.