Build and inspect an FxDK project
Compile each resource before treating a project export as deployable. The original runtime lab provides an actual build script used both by CI and by FxDK. That gives the walkthrough a concrete input and verifiable output instead of an invented build command.
Prepare the lab and compile it once
Download runtime-lab source, extract its folder as runtime-lab, and install Node 22 plus .NET SDK 10. The two CitizenFX package references and Legacy target are pinned inside the projects.
From the resource directory, run:
node build.mjsExpected outputs are dist/client/FD.Runtime.Client.net.dll and dist/server/FD.Runtime.Server.net.dll. A nonzero compiler exit or missing assembly fails the build script. Check these exact paths before opening FxDK: an editor with no syntax squiggles is not a compiler result.
Let FxDK call the same build entry point
Add the resource folder to a Windows FxDK project and enable it. Its manifest contains:
fxdk_build_command 'node' { 'build.mjs' }The FxDK resource manual documents this build hook and the separate watch-command facility. This lab deliberately has no watch command: a one-shot C# publish is appropriate for the example, while a real frontend bundler may need a long-running watch process during editing. Never use a watch process as a build command that is expected to terminate.
The lab’s root-level .fxdkignore excludes src/, tests/, bin/, obj/, the build script and development notes from the project output. It keeps the compiled dist/ assemblies and runtime JS/HTML. Review this file whenever a new runtime dependency is added; excluding a file from the export can break the resource even though the local source directory still works.
Build the project into a disposable output directory
Use FxDK’s project build interface, select a new output directory and choose artifact inclusion intentionally. According to the project-building manual , automatic server artifact inclusion is Windows-only; for Linux, omit it and provision the correct server artifact separately.
The default versioned resource/artifact directories help retain previous builds. Disabling versioning can delete the old destination when a new build is produced, so never use an irreplaceable production directory as an exploratory output path.
| Output | Inspection |
|---|---|
| Enabled resources | Only intended resources are included; all manifest script paths resolve. |
| Lab DLLs | Both exact .net.dll files exist, rather than only project/obj files. |
| Lab private banner | The server can read its sample file, but it is not in manifest files or shared/client scripts. |
variables.cfg | Generated configuration may contain sensitive Steam/Tebex settings; do not publish it. It can be overwritten by rebuilding. |
server.cfg | The manual distinguishes this preserved configuration from generated variables; add the server key privately. |
| Server artifact | Correct OS and track; not a historical binary copied only because it came from the previous output. |
A .fxdkignore exclusion controls what is copied to the project build. The resource manifest controls what a joining client receives. Those are different boundaries: a file can be present on the server without being client-distributed.
Run the exported build in staging
Start the build as a standalone development server using the current platform instructions. Grant the narrow docs.banner permission only to your tester, connect a compatible Legacy client and run /fd_banner, /fd_timer and /fd_form. Repeat with an ungranted session, malformed private JSON, a missing DLL and a resource restart. Use two-client testing for ID reuse and replication behavior that single-user FxDK cannot establish.
The resource’s build script, two assemblies and protocol tests were executed in CI. The FxDK graphical project-build action itself was not executed here. This walkthrough identifies its actual documented output and the concrete resource build, without relabeling a dotnet publish result as a GUI/in-game test.
Roll back cleanly
Stop the staging process, retain the failed output and logs for comparison, restore the previously known-good artifact/resource directories and use the matching private configuration/state backup. Do not reuse a database mutated by an incompatible runtime without a tested rollback plan. Enhanced disables built-in resource builders; use the track-specific migration checklist before applying any old build/deployment recipe there.