What is an .objoc file -- and other build questions

bgrommes

I just tried my first build of an Objo app on windows. It ended up in an appname\builds folder under where I have Objo installed (yay! I was afraid it would be an installer that would put it in the mysterious bit bucket on the system drive or something). But in the Windows x64 folder is the .exe and an app.objoc file. If I ever were to want to give this out beyond just this development box, would that have to be a companion to the .exe? What is it exactly?

When I pressed Build, I also got a macOS-Apple-Silicon folder (although not a Linux folder). So is the default behavior to produce (unsigned in my case) executables and related artifacts for all platforms? Why am I not seeing a Linux build? Not that it matters to me at this moment in time, just curious.

Also, one thing the MacOS build has that the windows executable doesn't is a couple of dylibs, for sqlite and something supporting native ports (serial ports, I take it). Is SqlLite and serial support built into the generated exe in the case of Windows?

Garry

Good questions!

The .objoc file is your application compiled into Objo bytecode, together with metadata such as its name and version. The .exe is the Objo runtime host that loads and executes that bytecode.

For the current Build output, app.objoc must therefore accompany the .exe in the same folder. The safest rule is to treat the entire target folder as one unit and copy all of it. In a macOS application bundle, the same file is stored inside the bundle’s Contents/Resources folder.

Build does not produce every platform automatically. It builds the targets selected for the project. Select the project in the Navigator, expand Build Settings in the Inspector, and look under Build Targets. If Windows x64 and macOS Apple Silicon appeared, those two targets are selected; no Linux folder appeared because neither Linux target is selected. New projects normally select only the current platform. You can additionally select Linux x64 or ARM64, although the resulting application should still be tested on the target system.

The two macOS libraries are native dependencies:

libe_sqlite3.dylib provides SQLite.
libSystem.IO.Ports.Native.dylib provides the native part of serial-port support.

The current bundled runtime includes those capabilities even when a particular application does not use them. macOS keeps these libraries as separate files because of its native-library loading and packaging model. In the Windows build, the equivalent native components are packaged inside the single-file executable and are extracted automatically when required. Their absence beside the Windows .exe does not mean SQLite or serial support is missing.

In short: keep app.objoc and any native libraries with the executable, and distribute the complete output rather than copying only the executable. Also, Build output is intended for local testing; when you are ready to give an application to other people, use Publish to create the appropriate distribution output for that platform.

madamov

@Garry

Not wanting to hijack topic, but I think it is related.

I just finished implementing creation of installer(s) using Inno Setup in GitHub actions workflow for one 4D project I am working on. I would like to integrate same feature to ObjoPublisher workflow I created for Objo. So, please confirm the steps are correct or not, because I think we can't use publishing, not sure how MSIX file would fit with Inno Setup.

Use build instead of publish
Sign content of destination folder
Use Inno Setup to create installer
Sign MyApp_Setup.exe created by Inno Setup
Distribute MyApp_Setup.exe

This is Windows only, of course.

bgrommes

madamov Yes, or, Publish should offer a portable zip packaging option.

Garry

Thanks for raising this. I think this is a genuine gap in the Windows publishing workflow.

I’ve added three Windows desktop Publish formats for the next Objo Studio release:

MSIX package — the existing/default option, with Azure Artifact Signing when configured.
Unpackaged application folder — a complete runnable folder suitable for code signing or use with an installer builder such as Inno Setup.
Portable ZIP — the same complete application folder packaged for portable distribution.

The folder and ZIP include everything the application needs: the .exe, app.objoc, runtime and native dependencies, deployed resources, and host settings.

app.objoc is the compiled Objo bytecode executed by the bundled runtime. It is therefore an intentional part of these outputs, not an intermediate file that can be deleted. Keeping the bytecode separate allows Studio to reuse the prebuilt runtime host rather than rebuilding the entire C# host for every application.

The folder and ZIP formats deliberately bypass MSIX packaging and Azure signing. Studio does not sign the individual .exe or DLL files in these outputs, so developers using a traditional installer should code-sign the applicable binaries in their external release pipeline before building the installer.

The same choices are available from the command line:

objo publish MyProject.objo --rid win-x64 --windows-format msix
objo publish MyProject.objo --rid win-x64 --windows-format folder
objo publish MyProject.objo --rid win-x64 --windows-format zip

MSIX remains the default when --windows-format is omitted. The folder and ZIP formats can also be produced for Windows through Studio’s advanced cross-host output when working on macOS or Linux.

This keeps Build focused on local development/testing output while giving Publish practical options for MSIX, traditional installer, and portable-app workflows.

This will be in the next release: https://feedback.objo.dev/feature/1129