1. Open deploytool in a graphical or advanced command-line Nelson session. Select the main .m file in Application, then choose the console target or, on Windows, the no-console target. Select an output directory. Build can be run again in the same directory when the previous report and application outputs remain unchanged.

2. Add extra application files or folders in Resources. Files such as .nh5 and .mat belong to Application resources when the executable needs them. Additional installer files are distributed by the installer instead of being embedded in the application.

3. Click Analyze to inspect source/archive paths and unresolved dependency diagnostics in Results and the log. Analysis does not create the build directory. Resolve missing dependencies before building.

4. Click Build. The editor calls compiler.build.standaloneApplication or compiler.build.standaloneWindowsApplication and lists the generated files. The build contains no copied runtime. Use an installed compatible runtime, or distribute one in the separate installer step. For EmbedArchive=false, distribute the adjacent .nca together with its executable.

5. On Windows, Installer contains destination, delivery and shortcut settings; Installer details contains application metadata; Installer images contains installer, logo and application-list icons. RuntimeDelivery=none requires an existing compatible runtime; installer includes a private runtime. Click Installer after a successful build to create the EXE or ZIP without installing it on the build machine. Inno Setup must be available to this operation. Web delivery is not implemented.

6. Save the project after a successful build to retain its build reference. New, Open and Close ask whether to save unsaved changes. Reopening verifies the build settings, report fingerprint, generated files, native launcher contract and archive before restoring the outputs for installer creation. Missing or changed outputs leave the configuration open with a diagnostic and no usable build. Editing build settings invalidates the previous result; editing installer metadata does not.

7. Export build script in Results writes the equivalent compiler.build commands to a .m file. It exports the build, not installer commands, and cannot replace an existing file. No project content is evaluated as executable code. The .ncproj JSON format is Nelson-specific, versioned and validated; saving writes the current versioned schema and enforces the 1 MiB limit. It is not a project interchange format for other applications.

Since format version 2, project files store paths inside the project file's directory as relative paths. This includes the main file, application and installer resources, file patterns, help text, images, build and installer output directories, and the shortcut source. Move this directory with its sources and build outputs, then open its .ncproj file to restore or rebuild from the new location. Relative paths are resolved against the project file, independently of Nelson's current directory. The editor and exported commands use the resolved absolute paths.

Files outside the project directory retain absolute paths and must be available or updated after a move. Saving under a different project filename recalculates relative paths without moving sources. RuntimeLogFile and DefaultInstallationDir keep their destination-machine meaning. Format 3 introduced LastBuild with report and build-settings fingerprints; format 4 added SourcesSHA256 for actual build inputs. Format 5 introduced TreatInputsAsNumeric. Versions 1 to 4 migrate with numeric conversion disabled; verified saved-build settings fingerprints are updated without approving changed settings. Versions 1 and 2 have no saved build; version 3 has no source fingerprint until rebuilt.

The Application tab includes Treat Inputs As Numeric. Select it to pass double scalars to the entry function, or leave it off for character vectors. The saved project and exported command retain this setting. See compiler.build.StandaloneApplicationOptions for conversion, invalid inputs and script behavior.

Opening a saved build, Analyze, Build and Installer check source freshness without executing application code. The fingerprint covers retained code and resources, selected directory contents and empty directories, lookup order, retained dependency definitions, application help and executable icon. It ignores timestamps and build-host path relocation. New files matching AdditionalFiles patterns are detected. Confirmed changes disable Installer until a new Build. No background watcher or application-runtime checks are added.

A restored build is the previously generated application, not a reconstruction from the current sources. If sources cannot be analyzed, including missing files or invalid source syntax, freshness is unavailable and the log explains why. Projects without a source fingerprint display an unknown source state. Neither state means the sources are current. The verified saved application can still be packaged without its sources; installer resources and any runtime files selected for bundling must remain available. Review the status and diagnostics before distributing that snapshot. The programmatic compiler.package.installer interface continues to consume frozen build results independently of source freshness.

Outputs and the report are checked again before packaging. Source checks describe the observed inputs; they do not lock the source tree against concurrent edits. Dynamic inputs outside dependency analysis are not monitored. Fingerprints detect changes; they are not publisher signatures.

Projects with missing source files can still be opened to repair them. A rebuild prepares new outputs before replacing the verified previous build; unrelated files are preserved, and modified outputs require a new destination. Changing the executable name also requires a different output directory. See compiler.build.standaloneApplication for publication and recovery rules. A project does not contain source snapshots, runtime binaries or credentials. Inspect resources and generated commands before distributing an application.

Project files are limited to 1 MiB. A save that exceeds this limit is rejected before replacing the existing project.

The Packages tab selects automatic detection, no registered packages, or a list of allowed installed nmm packages. Project format 6 records SupportPackages; older projects migrate to {'autodetect'} and retain valid saved-build receipts. Changing the selection invalidates the previous build settings.

deploytoolstandaloneApplicationCompilercompiler.build.StandaloneApplicationOptionscompiler_installer_tutorialcompiler_runtime_tutorial