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: Within our platform, we offer an elegant solution for managing project versions. Through this sophisticated tool, the capability to create a read-only iteration of a project, gracefully transitioning it into its released phasecopy of the Solution for deployment in controlled areas.
On this page:
| Table of Contents | ||||
|---|---|---|---|---|
|
Build
FeatureThe Build feature compiles all projectthe solution's displays and scripts for final verification before deploying the project for production . Build provides complete verification of an deployment. It ensures thorough validation of the application's scripts when preparing it for final production. However, this is not necessary during the development stage since all project 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 compiled in the background while a project is edited.
The section Build and Publish is presented on the following image.
editing the solution.
Field | IndexDescription | |
|---|---|---|
| 1 | Build button - The Build command does not need to be executed after a project is edited as it happens automatically in the background. The Build command only needs to be used as a final verification before a project 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 | 4 |
| 5 | Publish button create an only read version of this project, with the next configured version. | 6 | 7 |
| 8 | This table shows the current status of each script and display potential errors or warnings. |
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 an applicationit is being prepared for final production, but it is not necessary during the development process. Any modifications you make on a projectsolution are automatically and transparently compiled in the background while you are editing. |
A project's configuration is saved in a file with the extension "dbsln". Using the Publish procedure that is described in next section, you can create read-only versions of the project for runtime execution only. This version will have the extension ".dbrun".
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
Publishing Your Project
Click the Runtime → Build and Publish icon.
The Publish command creates a read-only protected version of a project that is suitable to be deployed in the field.
When the Publish command is executed, a new Project file (with the extension ".dbsln") is created with the version number selected. The Published Projects (with the extension ".dbrun") are similar to the current project and can be opened only in read-only mode. This provides you with a safe backup version of published applications.
| Note |
|---|
| A project does not need to be published unless a read-only protected version of the file is warranted. Otherwise, the project file needs to be copied to the target computer. |
Build and Pack Projects
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 projectsolution.
- 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 project file. If you want to save the project 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 Runtime
- / Build and Publish.
If you want to pack the database, select Pack database after build to significantly reduce the project file size. The system creates a file with the backup extension, which is the database before the application is packed. You may want to pack the database every time you run a build.
If you want to save all displays, select Verify Symbols and save all Displays. 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 project.
- Select the Rebuild All and Validade Displays options.
- Click Build.
| Info |
|---|
When checked, a backup of the project that is connected with the build is automatically created. It is also possible to pack a project without building. To do this, click the Pack button. |
Project Version Control
Tracking configuration changes
Our platform provides many ways to help you track the project configuration changes:
All configuration tables have the DateCreated and the DateModified information.The Project Settings → History page shows all Build commands executed in that project. According to your user settings, you may be able to access a backup version of the project with the settings and values it had when that version was built.The Track Changes → Version Control page shows all configuration tables, lists the number of rows, and shows if the tables were changed.The Track Changes → Recent Changes shows all project objects that have been modified. In order to enable or disable this, you must be logged in as an Administrator. By default, object tracking is only enabled after you publish the project, but you can enable it anytime.
Publishing the Project
Publishing the project creates a read-only version of the project.
It is NOT necessary to publish the project solution to install it for production. If the project solution is expected to have continuous changes when in the field, it is easier to put the main project 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 project file. The created file has the same name of the project's and it has the publish version number along with the ".dbrun" extension. This allows the solution file, allowing the system to comply with regulated industries.
The publish commandis usually used in case you want to:- Protect the project from modification. When deploy a read-only version of the project. 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 project build they are.
| Info |
|---|
The ".trun" file is always read-only, but you can optionally hide the project 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 project configuration, remove the permission of the GUEST user and other users to edit the project before publishing it. |
In this section:
| Page Tree | ||||
|---|---|---|---|---|
|