Runtime Build and Publish Reference

Build and publish your solution.

Reference → Solution → Runtime → UI → Startup | Build and Publish | Execution Profiles | Monitor

Build Operations

The Build command compiles the solution’s script classes, script tasks, script expressions and displays, records the result of every object in the grid, and increments the build number. Four check boxes on the Build panel change what the build actually does.

All four options are stored with the solution, so the state you leave them in is the state you find in the next Designer session. By default all four are cleared. Every build also records the options it ran with in its Solution History entry, so you can tell later how a given build number was produced.

Default build (no options selected)

Designer compiles each script and display in the background as you edit and save it, so most objects already carry a compile result before you press Build. With all four boxes cleared, the build recompiles only:

• objects that have never been compiled (no line yet in the build grid), and
• objects whose last compile reported errors or warnings.

Everything else is left untouched and counted in the Up-to-date figure of the build summary. This is the fast, everyday build.

Save Backup

Saves a backup copy of the solution file before the first object is compiled, so the backup always reflects the solution as it was going into the build, and marks the build entry in Solution History as having a backup. That entry is what you select to roll the solution back to this build.

• Selecting Rebuild All turns Save Backup on automatically. You can clear it again, but the pairing is intentional: a full rebuild rewrites the compiled output of every object in the solution.
• Recommended before a version upgrade, a mass import, or any build you may need to undo.

Rebuild All

Rebuilds the solution from scratch instead of only recompiling what is out of date. Besides compiling every script class, script task, script expression and display, it:

• clears the build result grid and re-checks the solution database schema;
• refreshes all solution types (tags, templates, user-defined types) before compiling, and reports circular template definitions as warnings;
• runs extra dependency passes over the script classes, so a class that depends on another class compiled later in the same pass is retried instead of being reported as an error.

The first Rebuild All in a solution asks for confirmation, because it compiles everything and takes considerably longer than the default build. Use it before publishing, after upgrading a solution from a previous product version, after restoring or importing a solution, or whenever the reported build results look inconsistent with the configuration.

Validate Displays

Goes beyond compiling the display code: the build opens each display, renders it off-screen, and saves it back. For every display this means:

• the display is instantiated with all of its controls, symbols and dynamics, so problems that only appear when a display is loaded — a missing symbol, an invalid control property, a broken dynamic — are reported at build time instead of failing in front of the operator;
• the generated XAML and the display expressions are regenerated and saved;
• the thumbnail shown in the Displays list is refreshed.

This is the slowest option, since displays are loaded one at a time. Use it before publishing, after a version upgrade, and after mass edits to symbols or templates. The option is not available on EdgeGateway, which has no display runtime.

Debug Information

Makes the compiler emit debug symbols and the generated source files alongside the compiled assemblies in the build temp folder. This is what allows the Script Debugger to work:

• breakpoints can only be set while Debug Information is enabled — otherwise Designer reports that debug information is disabled;
• the attach-debugger options for Startup and Test runs are shown only while it is enabled;
• clearing the check box deletes the generated source and symbol files from the temp folder.

Symbols are emitted anyway while a debugger is attached, whatever the check box says. Leave the option cleared for production builds: it adds time to every compile and leaves generated sources and symbols on disk. The check box is shown only where the Script Debugger is available.

Temp Files

Selects where the compiler writes its working files — generated sources, compiled assemblies and, when Debug Information is enabled, debug symbols.

When to Build

Build is automatic during development but manual build is useful for:

Build Process Steps

1. Navigate to Runtime → Build and Publish
2. Select Rebuild All and Validate Displays
3. Click Build
4. Review build results
5. Fix any errors shown

Publish Operations

Publish Process

Creates read-only .dbrun file for production:

Version Management

Build Status

Background compilation provides continuous validation:

Double-click any row with issues to navigate to source.

Build vs Publish

Build Only

Suitable when:

• Continuous development expected
• Frequent field changes
• Development environment
• Testing iterations

Publish Required

Necessary for:

• Regulated industries
• Locked production systems
• Version control
• Read-only deployment

Validation Results

Warning Types

Warnings are informational:

• Won't stop execution
• May indicate potential issues
• Should be reviewed

Error Types

Errors prevent execution:

• Script won't run
• Display won't load
• Must be fixed

Best Practices Checklist 

Development Phase

• Use automatic background compilation
• Fix errors as they appear
• Don't build unnecessarily

Pre-Production

• Run full build with all options
• Fix all errors
• Review warnings
• Create backup

Production Deployment

• Final build and validation
• Set version number
• Publish solution
• Archive .dbrun file

File Types

Troubleshooting

In this section...