HomePowerBuilderAppeon Documentation Center

Build page

The Build page > Basic tab has the following settings:


Option or option group

What you specify

Rebuild

Specify how to build the application:

  • Full -- Regenerates and redeploys all object files to the server. It is strongly recommended that you always select Full if you build and deploy the project to the production environment.

  • Incremental -- Regenerates and redeploys only objects that have changed, and objects that inherit or reference any objects that have changed, since the last time you built the application.

  • Cursory (ultra-fast) -- Regenerates and redeploys only objects that have changed. Unlike Incremental, Cursory will not generate objects that have inheritances or references with the changed object. Therefore, Cursory should be used 1) after the project has been full built, 2) only independent objects have been changed or the change has no impact on the other objects.

    For Cursory (ultra-fast) to take effect, you will need to enable the option "At every save, create temp files required for cursory (ultra-fast) rebuild" in the Application Properties | PowerServer tab (it is not selected by default). After you enable the option, please perform a Build & Deploy on the PowerServer project using the Full build option before selecting Cursory (ultra-fast).

    Note

    After the user selects the option "At every save, create temp files required for cursory (ultra-fast) rebuild", PowerBuilder IDE will generate two types of temporary files whenever the object is added/imported/copied/changed and then saved in the IDE:

    1. runtime files of the current saved object(s), which are stored in the "[pbtname]_pbobjects" folder under the current application target;

    2. handles of the ESQLs in the current saved object(s), which are stored in the user's temporary directory.

    And then during the build and deployment process of Cursory (ultra-fast), the IDE will perform the following actions:

    1. Directly upload the runtime files from the "[pbtname]_pbobjects" folder and the index file of the object PBD to the corresponding directory in the client app;

    2. Generate models from the DataWindows in the "[pbtname]_pbobjects" folder and upload them to PoweServer Web APIs;

    3. Upload the handles of the ESQLs from the user's temporary directory to PowerServer Web APIs.

    IMPORTANT: The "[pbtname]_pbobjects" folder and the associated temporary files are used specifically for the purpose of Cursory (ultra-fast) rebuild in the current project, and they will be removed immediately after the rebuild process is completed for the current project. That is to say the temporary files are not retained or used for subsequent rebuilds or for other PowerServer projects.

    Cursory (ultra-fast) does not support 1) deploying to External > IIS or Folder (Incremental will be used automatically), 2) new PBD files, 3) object moving and removing, 4) directory changes, 5) object(s) obtained from source control.

    If the object is obtained from the source control server, the object will not be exported and stored in the "[pbtname]_pbobjects" folder.

    Now that we understand the cursory rebuild is specific to only the changes in the current object. If there are changes that should be applied globally (such as global variables or global external functions), and if they are modified and saved in a non-application object, then only the current object will be updated during a cursory rebuild (the application object will not be updated). This means the application object will not reflect the changes. As a result, when running the application, an exception may occur due to missing definitions. To work around this issue, when adding or modifying global variables or global external functions, it is recommended to perform an incremental or full build (to update all objects, including the application object, with the necessary changes). Alternatively, you can open the application object, make a small change (e.g., adding a comment), and save it (this will create temporary files of the application object and the cursory rebuild will be able to update the application object with the necessary changes).

Platform

Select if the client app can run on 32-bit or 64-bit machines.

Enable DEBUG symbol

Select to enable any code that you placed in DEBUG conditional code blocks. For more information, see Using the DEBUG preprocessor symbol in PowerBuilder User Guide.

Target framework

Select the .NET version the solution is targeting.

Web API solution location

Specify the location for the PowerServer C# solution.

If the PowerServer C# solution already exists, you can deploy the app to the existing solution, the application data models and ESQLs will be updated in the solution, and if you deploy a new app to an existing solution, the application data models and ESQLs will be added to the existing solution.

For more information, refer to Generate the PowerServer C# solution.

Timeout

Set timeout values (in seconds) for session, transaction, and request.

For more information, refer to Configure the timeout settings.

MaxSPCache

Specify the maximum number of stored procedures for which the driver caches information.

The driver retrieves information from the server about a stored procedure's parameters the first time the stored procedure is called and caches that information. The next time the procedure is called, the driver retrieves the information from the cache to improve performance. You can turn off caching by setting the value of MaxSPCache to 0.

Overwrite server settings

Choose whether to overwrite the server settings (such as the database connection, timeout values, PowerServer license etc.) and the authentication template in the solution, when you deploy to the same or existing solution.

For more information, refer to What settings will be deployed to the solution.


The Build page > Advanced tab has the following settings:


Option group

What you specify

Libraries

Specify a PBR file for a dynamic library if it uses resources (such as bitmaps and icons) and you want the resources included in the dynamic library instead of having to distribute the resources separately.

You can type the name of a PBR file in the box or click the button next to the box to browse your directories for the PBR file you want to include. The PBR file as well as the resources it references must reside in the application directory or subdirectory; and only relative paths of the PBR file and the resources will be accepted.

Versioning

Deployment version -- The deployment version number is used by the server to determine whether to perform an install or update for the application on the client. It is recommended to increment the deployment version number every time when the application is updated and re-deployed. For more, refer to Manage app versions/updates.

Minimum compatible version -- Specify the lowest compatible version for the application. If the version installed on the client is older than it, a forced update will be performed, or the application will stop running. For more, refer to Manage app versions/updates.

Note

To effectively manage version compatibility and prevent issues when upgrading the application, you should follow these guidelines when defining Deployment version and Minimum compatible version (the rules of comparing the versions are similar to the rules of sorting the file name in Windows):

  • You should always increase the version number, for example, from 1.0.3 to 1.0.4, and should NOT decrease the number, for example, from 1.0.3 to 1.0.2.

  • You should use the consistent versioning scheme/structure, that is to say, the same total length, the same total segments, and the same length and format in each segment.

    Here are a few correct and incorrect examples:

    √: Deployment version: 1.01, Minimum compatible version: 1.00

    X: Deployment version: 1.2, Minimum compatible version: 1.00 (incorrect, because these two numbers have different lengths in the second segment)

    √: Deployment version: 1.10, Minimum compatible version: 1.09

    X: Deployment version: 1.10, Minimum compatible version: 1.9 (incorrect, because these two numbers have different lengths in the second segment)

    √: Deployment version: 23.0.0.1, Minimum compatible version: 23.0.0.0

    X: Deployment version: 23.0.1, Minimum compatible version: 23.0.0.0 (incorrect, because these two numbers have different segments)

Available time -- Schedule the time for the deployment version to be accessible to end users.

Expiration time -- Schedule the time for the deployment version to be inaccessible to end users.

If the available time or expiration time is reached and the app is still open, the app will not get updated, until the app is closed or the session times out. Therefore, it is recommended that the session timeout feature should be enabled (for apps deployed via PowerServer) or implemented (for apps deployed via PowerClient).

Version used by the installer > Product version -- Specify the product version (in numeric values) that will be used by Microsoft Installer to determine whether a product needs to be updated.

Version used by the installer > File version -- Specify the file version (in numeric values) that will be used by Microsoft Installer to determine whether a file needs to be updated.

Product name, Company name, Description, Copyright, Product version, File version -- Specify your own values for these fields associated with the application file and with machine-code DLLs. These values become part of the Version resource associated with the application file, and most of them display on the Version tab page of the Properties dialog box for the file in Windows Explorer. The Product and File version string fields can have any format.

The four numbers can be used to represent the major version, minor version, point release, and build number of your product. They must all be present. If your file versioning system does not use all these components, you can replace the unused numbers with zeros. The maximum value for any of the numbers is 65535.


Others

Windows classic style -- Select this to add a manifest file to the application that specifies the appearance of the controls as an application resource.

By default, this option is not selected, which means the Windows flat style is used and the 3D effect of some controls will be removed to have a "flat" look, for example, the 3D lowered border of Column and Computed Field in the DataWindow object, the background color of Button, the BackColor and TextColor of the tooltip, and the TabBackColor of tab header will not take effect. If you still want the 3D effect, you should select the "Windows classic style" option when deploying the application.

Note

If you have applied a theme to the application, you should not check the "Enable Windows Classic Style in the IDE" option in the System Options or the "Windows classic style" option in the project painter and the PB.INI file (if any) should not contain such setting, otherwise, the application UI will be rendered in the Windows classic style instead of the selected theme.


Prev  Up  Next
Database page  Home  Deploy page