The Build and Publish page provides commands for compiling solutions and creating deployment packages. Build validates scripts and displays, while Publish creates read-only production versions.
Access: Runtime → Build and Publish
Parent Page: Runtime Designer UI (Reference)
Build Operations
Build Process
The Build feature compiles displays and scripts for final verification:
| Option | Function | When to Use |
|---|---|---|
| Build | Execute compilation | Before deployment |
| Save Backup | Create .dbbak file | Major changes |
| Rebuild All | Complete recompilation | Full validation |
| Validate Displays | Check UI components | Display changes |
Build Settings
| Setting | Options | Purpose |
|---|---|---|
| Temp Folder | Designer Settings / ProgramData | Workspace management |
| Debug Information | Include debug data | Development troubleshooting |
Temp Folder Locations
- Designer Settings:
SolutionPath\DesignerSettings\ - ProgramData:
\ProgramData\FrameworX\
When to Build
Build is automatic during development but manual build is useful for:
| Scenario | Purpose |
|---|---|
| Many changes made | Full validation |
| Assign build number | Version tracking |
| Pack database | Optimize storage |
| Before publishing | Final verification |
Build Process Steps
- Navigate to Runtime → Build and Publish
- Select Rebuild All and Validate Displays
- Click Build
- Review build results
- Fix any errors shown
Publish Operations
Publish Process
Creates read-only .dbrun file for production:
| Setting | Function | Result |
|---|---|---|
| Publish | Create deployment file | SolutionName_Version.dbrun |
| Version | Current version number | Auto-incremented |
| Next Increment | Version strategy | Major/Minor |
Version Management
| Increment Type | Example | Use Case |
|---|---|---|
| Major | 1.0 → 2.0 | New features, breaking changes |
| Minor | 1.0 → 1.1 | Bug fixes, small updates |
Build Status
Background compilation provides continuous validation:
| Status | Indicator | Action Required |
|---|---|---|
| Green | ? | None |
| Warning | ?? | Review recommended |
| Error | ? | Fix required |
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
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
| Extension | Type | Purpose |
|---|---|---|
| .dbsln | Solution file | Development version |
| .dbbak | Backup file | Build backup |
| .dbrun | Published file | Production deployment |
Troubleshooting
| Issue | Cause | Solution |
|---|---|---|
| Build fails | Script errors | Check error list |
| Publish disabled | Build errors exist | Fix all errors first |
| Large file size | No compression | Enable database packing |
| Version conflict | Manual edit | Use version controls |
See Also
- Runtime Designer UI (Reference) - Parent section
- Runtime Startup (Reference) - Execution settings
- Solution History (Reference) - Build tracking
- Solution Deployment (Guide) - Production setup
Overview
As you do the Solution Configuration, the system automatically compiles Scripts and Displays, with no user intervention.
In specific situations, like preparing the solution for Deployment, or creating a solution backup, or just wanting to have a deeper validation, this page provides the following optional commands:
Build: compile and verify Scripts and Displays, apply a Build Number to facilitate version control.
Publish: create a read-only copy of the Solution for deployment in controlled areas.
On this page:
| Table of Contents | ||||
|---|---|---|---|---|
|
Build
The Build feature compiles the solution's displays and scripts for final verification before production deployment. It ensures thorough validation of the application's scripts and components as part of production preparation. Additionally, after each Build, the software logs an event in the Solution History, allowing the solution to be rolled back to its post-build state.
During development, this process is unnecessary, as modifications are automatically and transparently compiled in the background while editing the solution.
Field
Description
Build
Executes the build process for final verification before deployment. Use this command to ensure all scripts and components function correctly. This command generates a build number and logs the event in the Solution History.
Save Backup
When checked, this option creates a backup copy of the build with the .dbbak extension. This feature allows users to restore the previous state if needed.
Rebuild All
Initiates a complete rebuild of all components in the solution. Use this option to ensure that all changes are compiled together, regardless of prior modifications.
Validate Displays
Runs validation checks on all display components within the solution. This step confirms that all user interfaces meet the necessary standards before deployment.
Temp Folder
Specifies the location for temporary files created during the build process. This folder helps manage workspace and storage during compilation.
The Temp Files options \Designer Settings means the temporary folder will be created in the DesignerSettings folder, located in the same path as the solution is \ProgramData means the temporary folder will be created inside the \ProgramData\FrameworX\ folder
Debug Information
Enables the inclusion of debugging data in the build. The user must also enable Debug in the Trace Window Settings dialog.
| Note |
|---|
Executing a Build is useful for achieving complete verification of an application's logic when it is being prepared for final production, but it is not necessary during the development process. Any modifications you make on a solution are automatically and transparently compiled in the background while you are editing. |
Publish
After clicking the “Publish” button, a read-only protected version of the solution suitable for safe deployment on the field is created. This new version will have the same name as the Solution followed by its version number and will be of the .dbrun format.
Field
Description
Publish
Initiates the publishing process, saving content to the specified version. Confirms that all changes have been completed and content is ready for release to users.
Publish as Version: 1.0
Displays the version in which the content will be published. Allows users to verify the assigned version before publishing. The version number is typically generated automatically based on the selected version increment settings.
On Next Version Increment options
Displays options for defining the next version increment. Guides users to select either a major or minor update for future releases, ensuring version tracking and management.
Major number
Sets the next version increment to a major release. Selecting this option applies a significant version update, indicating broad changes or new features, for example, advancing from version 1.0 to 2.0.
Minor number
Sets the next version increment to a minor release. Selecting this option applies a smaller version update, representing adjustments or incremental enhancements, such as moving from version 1.0 to 1.1.
The platform constantly compiles the modules you edit in the background and validates all scripts and displays. If you have not run a full build, the BuildStatus column reflects any warnings or errors found during the background compile process.
If a row has a red X, double-click it to go to the source of the warning or error. Warnings are informational and do not stop the script from running. Errors prevent the specified script from running but do not affect the whole application. Even if a script or display has a warning, it will still run.
Periodically, you should run a full build:
- When you have made many changes and you want full validation and to recompile the whole solution.
- When you want to assign a build number to a version.
- When you want to pack the database.
- When you are getting ready to publish, that is, create the read-only runtime application.
To run a Full Build:
- Go to Runtime / Build and Publish.
- Select the Rebuild All and Validade Displays options.
- Click Build.
It is NOT necessary to publish the solution to install it for production. If the solution is expected to have continuous changes when in the field, it is easier to put the main file (.dbsln) directly on the production computer.
The main benefit of publishing is that the system creates a compact and read-only version of the solution file, allowing the system to comply with regulated industries.
In this section:
| Page Tree | ||||
|---|---|---|---|---|
|