Mastering the [SETTINGS] Section in Uniface Assignment Files

If you are developing enterprise applications with Uniface, you know that the Assignment File (.asn) is the nervous system of your application's runtime configuration. While sections like [ENTITIES] or [DRIVER_SETTINGS] often get the spotlight during database setup, the [SETTINGS] section is where the battle for a stable, environment-agnostic runtime is won.

In this post, we’ll dive into what the [SETTINGS] section actually does, the correct syntax for resource loading (fixing common misconceptions), and how to architect it for Development vs. Production environments.

What is the [SETTINGS] Section?

The [SETTINGS] section is used to define Uniface Logicals and Kernel settings. These are environment variables specific to the Uniface runtime that are loaded before your application logic starts. They control how Uniface behaves—how it finds code, where it logs errors, and how it handles dates or strings.

The syntax is straightforward:

[SETTINGS]
$VARIABLE_NAME = value

The Core Strategy: Resource Loading

The single most critical setting in modern Uniface (9.7 through 10.4) is $SEARCH_RESOURCES. This logical controls the order in which Uniface looks for compiled components (Forms, Services, DSPs).

⚠️ Common Pitfall: "Filesystem First"

A common mistake is trying to use a value like filesystem_first. This is not a valid keyword. If you want Uniface to look at your local files before checking the UAR archives, you must use resources_last.

Here are the valid strategies:

• resources_only (Production Standard) Uniface completely ignores the file system and only looks inside the UAR (Uniface Archive) files defined in the [RESOURCES] section. This is mandatory for high-performance, secure production environments.
• resources_last (Development Standard) Uniface checks your local folders (e.g., \uo) first. If it doesn't find the object there, then it checks the UARs. This is ideal for development because you can compile a form and test it immediately without rebuilding a UAR.
• resources_excluded (Default) Uniface never looks in UAR files.

Abstracting Environments with Logicals

Never hardcode paths in your ProcScript or C# bridges. Instead, define them in [SETTINGS] and access them via $logical.

In your ASN file:

[SETTINGS]
$EXPORT_DIR = C:\\MyApp\\Exports
$LOG_DIR    = C:\\MyApp\\Logs

In your Uniface Code:

; Instead of "filedump/append field, 'C:\\MyApp\\Logs\\err.log'"
filedump/append vErrorField, "%%$logical("LOG_DIR")%%%\\error.log"

This abstraction makes migrating your app from Windows to Linux (or Docker containers) as simple as swapping the ASN file.

Configuration Templates

Here is how you should structure your assignment files for different stages of your pipeline.

A. The Development Setup

In development, you need flexibility and verbose logging.

[SETTINGS]
; STRATEGY: Check local files (./uo) first, check UARs last.
$SEARCH_RESOURCES = resources_last

; LOGGING: Redirect the output window to a file for analysis
; Note: Use the correct underscore syntax for Uniface 10+
$PUTMESS_LOG_FILE = .\\logs\\uniface_dev.log

; DEBUGGING: Enable extended IO info in the log
$IOPRINT = 255

; Custom App Settings
$APP_ENV = DEV

B. The Production Setup

In production, you need speed, security, and immutability.

[SETTINGS]
; STRATEGY: Only load signed/packaged code from UARs
$SEARCH_RESOURCES = resources_only

; DISABLE DEBUGGING features
$TEST_MODE = 0

; Custom App Settings
$APP_ENV = PROD

Troubleshooting Guide

Conclusion

The [SETTINGS] section is your control center for the Uniface runtime. By correctly utilizing $SEARCH_RESOURCES = resources_last for development and resources_only for production, you create a robust workflow that supports both rapid iteration and stable deployment.

Note: This article was created with the assistance of AI based on official Uniface 10.4 documentation to explain core security concepts and provide practical implementation details.