Having Coverage Validator launch your program is the most common way to start up
When you're ready to start running a .Net Core program
 Launch menu 
 Applications 
 Launch .Net Core Application 
 Shows the .Net Core launch dialog below 
Or use the shortcut
 
 + 
  Launch .Net Core Application
You can easily re-launch the most recently run program. 
 
.Net Core applications can be self contained or framework dependent. This changes how the launch dialog works.
•.Net Core application type 
 choose which type of .Net Core application you are launching 
•Application to launch (*.exe) 
 type or Browse to set the program name (*.exe) to launch 
When you set this value the Application to launch DLL field will be automatically populated to have the same name as the EXE field but with a .DLL extension.
•Application to launch (*.dll) 
 type or Browse to set the program name (*.dll) to launch 
•Application to monitor 
 choose the application that actually gets monitored 
 
This will typically just be the program that you set to start - unless otherwise specified.
Alternatively you can monitor another application which will get launched by the start program.
If the start application has already been added to the Applications to Monitor settings with a default application then that default will be entered here automatically.
Otherwise, if nothing has been set up yet, you can do it from here:
•Edit... 
 set the child applications that can be monitored for the start program 
This uses the Applications to Monitor dialog - which is exactly equivalent to using the Applications to Monitor settings page.
A fallback option is to start monitoring <<Any application that is launched>>.
  
 If in doubt, just use the same as the start application. 
See also: Application to Monitor settings
•Application to launch (*.exe) 
 type or Browse to set the program name (*.exe) to launch 
We don't auto-populate this field when you choose the Framework dependent application type. This because you may have your .Net Core runtime stored in a location that we can't auto-detect.
To accommodate alternate locations for the .Net Core runtime we only auto-populate this field if it is empty when you choose the application DLL.
•Application to launch (*.dll) 
 type or Browse to set the program name (*.dll) to launch 
If you set this when Application to launch EXE field is empty, the EXE field will be automatically populated with the path to the system .Net Core framework dependent runtime.
This is typically c:\program files\dotnet\dotnet.exe.
•Application to monitor 
 choose the application that actually gets monitored 
 
This will typically just be the program that you set to start - unless otherwise specified.
Alternatively you can monitor another application which will get launched by the start program.
If the start application has already been added to the Applications to Monitor settings with a default application then that default will be entered here automatically.
Otherwise, if nothing has been set up yet, you can do it from here:
•Edit... 
 set the child applications that can be monitored for the start program 
This uses the Applications to Monitor dialog - which is exactly equivalent to using the Applications to Monitor settings page.
A fallback option is to start monitoring <<Any application that is launched>>.
  
 If in doubt, just use the same as the start application. 
See also: Application to Monitor settings
•.Net Core dotnet.exe arguments 
 any arguments that will be passed to the .Net Core runtime to control how the .Net Core runtime behaves. 
•Edit... 
 displays the .Net Core runtime arguments editor 
•Launch Count 
 when monitoring a child application, set its nth invocation as the one to monitor 
If the application to start is the same as the application to monitor then this is set to 1 and cannot be changed.
This will be reset to 1 every time the Application to Monitor field selection changes.
 If in doubt, leave it set to 1. 
See also: Launch Count.
•Command Line Arguments 
 enter program arguments exactly as passed to the target program 
•Startup Directory 
 enter or click Dir... to set the directory for the program to start in  
 
When setting your target program, this will default to the location of the executable
•Environment Variables 
 click Edit... to set any additional environment variables before your program starts  
 
These are managed in the Environment Variables Dialog.
•File to supply to stdin 
 optionally enter or Browse to set a file to be read and piped to the standard input of the application 
•File to supply to stdout 
 optionally enter or Browse to set a file to be written with data piped from the standard output of the application 
 
 
The list at the bottom of the wizard shows previously run programs.
Selecting an item in the list populates all the details above as used on the last run for that program.
You can still edit those details before starting.
•Full path 
 shows the full path to the executable in the list
 
•Image Name 
 shows the short program name without path
•Delete 
 removes a selected program from the list
•Reset 
 clears all details in the wizard - including the list of previously run applications below
•Type of data collection 
 Are you only interested in Native data, .Net data or both Native data and .Net data? 
•Native Only 
 Ignore all .Net data in the target application. 
•.Net Only 
 Ignore all Native data in the target application. 
•Mixed Mode 
 Collect both Native and .Net data from the target application 
This setting cannot be changed after the application is launched
•Collect data from application 
 If it's the startup procedure you want to validate, obviously start collecting data from launch. 
Depending on your application, and what you want to validate, you may want to start collecting data immediately, or do it later.
If your program has a complex start-up procedure, initialising lots of data, it may be much faster not to collect data until the program has launched.
See the section on controlling data collection for how to turn collection on and off after launch. 
The data collection option may be disabled because of the instrumentation mode that is selected.
•Redirect standard output 
 Controls redirection of stdout and stderr
Use this option if you want to collect the output of stdout and stderr for later analysis.
Be aware that if the output of the program under test generates a lot of data via stdout or stderr that this data will need to be stored in memory and could exhaust Coverage Validator's memory.
•Display command prompt 
 Shows or hides the launched application.
If you are collecting stdout and stderr you may not be interested in viewing the application (or the command prompt if it is a console application). This provides you the option to hide the application when it is running.
Be aware that if you hide a command prompt you will not be able to type anything into the application.
The option to start collecting data is at the top.
•Launch 
 start your program and attach Coverage Validator to it 
Double clicking a program in the list will also start it immediately.
•Cmd Line... 
 display the command line builder 
If administrator privileges are required, the Launch button will show the privileges icon reminding you of the need to restart.

•Launch 
 shows the Administrator Privileges Required confirmation dialog before restarting 
  
If you started Coverage Validator in administrator mode, you won't see any of these warnings, and everything will behave as normal.
The three fields Application to Start, Application to Monitor and Launch Count work together to control which application actually gets monitored by Coverage Validator.
Let's say we have a program P.
In the simplest case, simply:
•start P
•monitor P
•the Launch Count defaults to 1 and cannot be changed.
If P launches an application and you just want to monitor whatever that is:
•start P
•monitor <<Any application that is launched>>
•leave the Launch Count at 1
If P launches an application A and maybe others as well, and you specifically want to monitor only A as it's launched:
•use the Application to Monitor settings to add a definition for P and child applications A
•start P
•monitor A
•leave the Launch Count at 1
If P launches an application A many times and you specifically want to monitor the third invocation:
•use the Application to Monitor settings to add a definition for P and child applications A
•start P
•monitor A
•set the Launch Count to 3