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 verification validation of the application's scripts and components as part of the production preparation for production.. 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.
Build compiles all the solution's displays and scripts, providing a final check before deploying the application into production. During development, this process is not necessary unnecessary, as modifications are automatically and transparently compiled in the background while editing the solution.
The section Build and Publish is detailed in the following image.
Field | Index | Description | |
|---|---|---|---|
1 | Build button, The Build command does not need to be executed after a solution is edited as it happens automatically in the background. The Build command only needs to be used as a final verification before a solution is deployed or for when a build number is needed. | ||
2 | If checked, a backup copy of this build will be created with the extension .dbbak | ||
3 | Be sure to use this option if you have made changes to the symbol library. This option applies to all symbol library changes throughout the solution. | ||
4 | Checking this box will make sure debug information is included. | ||
5 | Publish button create an only read version of this solution, with the next configured version. | ||
6 | Option used for managing solution versions. | ||
7 | Option used for managing solution versions. | ||
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. This feature assists developers in troubleshooting issues by providing additional context during runtime | 8 | This table shows the current status of each script and display potential errors or warnings. |
| 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
The Publish command generates After clicking the “Publish” button, a read-only protected version of a the solution ready suitable for field deploymentsafe deployment on the field is created. This command produces a new Solution file (".dbsln") with the chosen version number. The Published Solutions (".dbrun") mirror the current solution but are accessible only in read-only mode, offering a secure backup of published applications.
Click the Runtime Build and Publish icon.
The Publish command creates a read-only protected version of a solution that is suitable to be deployed in the field.
When the Publish command is executed, a new Solution file (with the extension ".dbsln") is created with the version number selected. The Published Solutions (with the extension ".dbrun") are similar to the current solution and can be opened only in read-only mode. This provides you with a safe backup version of published applications.
| Note |
|---|
A solution does not need to be published unless a read-only protected version of the file is warranted. Otherwise, the file needs to be copied to the target computer. |
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. The created file has the same name of the solution and it has the publish version number along with the ".dbrun" extension. This allows the system to comply with regulated industries.
The publish commandis usually used in case you want to:Protect the solution from modification. When deploy a read-only version of the solution. For instance, to be in compliance with certified and regulated environments.
Use the automatic version numbering system. The result of publishing is a ".dbrun" file that also contains a major (1.0) or minor (0.1) version number as part of the file name. In addition, Track Changes helps you manage the files published to the field, including which solution build they are.
| Info |
|---|
The ".dbrun" file is always read-only, but you can optionally hide the solution configuration from the end-user as well. This is an independent option defined in the Security System. If you do not want end-users to see the configuration, remove the permission of the GUEST user and other users to edit the solution before publishing it. |
Pack
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 The platform constantly compiles the module 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 a 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 the build executes, the system creates a backup of the current solution file. If you want to save the solution as it was for the build, rename the backup file.
- When you are getting ready to publish, that is, create the read-only runtime application.
To build the applicationrun a Full Build:
- Go to to Runtime / Build and Publish.
Configure the parameters according to your needs.
Click Build.
- 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 | ||||
|---|---|---|---|---|
|