Project Settings


Backup patched files

Create backups of all existing files that are being patched before overwriting them and store them in the specified Backup folder. Each existing file being patched will be renamed to filename.bak. If filename.bak already exists, it will be named filename.bk1, or filename.bk2, etc.

Backup folder:

The folder on the user's system that each backed up file will be created in.

Enable file rollback support

Make the patch rollback the already patched files to their original state if an error occurs during the patching stage, or if the user aborts the patching stage by clicking the Cancel button. The "patching stage" is the stage when the files are actually being patched on the user's system. No rollback is performed if the user cancels before or after this stage.

If the Backup patched files option is selected, the rollback will use the backed up files from the Backup folder. If the Backup patched files option is not selected, the patched files will be backed up to a unique folder in the user's Temp folder.

Delete legacy files

Delete all legacy files on the user's system when patching. A file is considered to be a "legacy file" if it exists in an older version, but is not part of the current version (not in the current version's file list).

Application Settings

Use custom icon:

Display a custom icon in the top left corner of your patch window.  It will also be used to represent the patch on the Windows task bar. Click the Browse button to open the Insert File Reference dialog where you can select an existing standard icon (.ico) file from your project's Primer Files list, or add one. After the file has been selected, this field will contain the location to reference the icon file during the patch.

Hide taskbar icon

Hide the taskbar icon during the patch.

Always on top

Make the patch window always appear on top of all other windows on the desktop. The window will remain on top even if the user switches to another application.

Enable silent mode

Enable the patch to be run in "silent mode" using the /S command line option. This means that there will be no user interaction required during the patching process. If you are performing silent patching, it is highly recommended that you use a log file during the patching process so that you can debug the patch if problems occur.

Note: Screen actions will only be executed if screens are displayed, therefore when run in silent mode, no screen actions will be executed.

Start in silent mode

Start the patch in "silent mode" by default.  If unchecked, you can run your patch in silent mode using the command line option /S, for example C:\Output\patch.exe /S. Selecting this option sets the global variable _SilentPatch to true.

Log File

Create log file

Generate a log file during the patching process. The patch log file is in ASCII text format and provides information about what happened during the patching process, such as which files were patched, which programs were executed, what Registry changes were made, etc. This information can be extremely useful if you ever need to debug a patch where errors occurred.


The location and filename of the log file to generate. You can specify an absolute location such as C:\Temp or you can use session variables to form dynamic paths such as %TempFolder%\logfile.txt.

Note: You should always create your log files in a pre-existing, standard system directory such as %TempFolder% or %WindowsFolder%.

Write mode:

How the log file will be updated if there is currently a log file in the target location. Choose from:


Append any new log file entries to the end of the existing file.


Overwrite the existing log file when generating the current one.

Include action details:

The action details that will be included in the log file. Choose from:


Don't log any errors in scripts in the log file.


Log errors in scripts with the event the error occurred in, the line it occurred on and the error message or code.

Extended Errors

Same as Errors but the actual line of code executed will be reported as well (if available).

Requested User Privilege Level

This section specifies which requested execution level to include in the patch's application manifest for distribution on Windows Vista or later. Patches should generally always be built using the default "Require administrator" setting. Before changing this default setting, see Patching On Windows Vista or Later for important information concerning required changes to your patch, and feature limitations.

Note: Changing the application manifest to "Highest available" or "As invoker" is only supported on Windows 2000 or later in Visual Patch's design environment.

Note: For more information on the settings below and general Windows Vista or later information, see Patching On Windows Vista or Later.

As invoker

The patch runs with the same access token as the parent process. For example, if the user is logged in as a standard user, those are the privileges they will inherit during the patch. This option should only be used in special circumstances where you are certain you do not need access to protected areas of the operating system.

Highest available

The patch runs with the highest privileges the current user can obtain. This setting is designed for applications that can be run by all users. It is most useful for applications that require privileges above that of a limited user, but less than a full administrator.

Require administrator (default)

The patch requires to be run with the full access token of an administrator. Generally patches make changes to protected system locations that are typically writable to only by administrator users. This is the default setting for patches created with Visual Patch.