Skip to main content

Share and Deploy Extensions

Code Lab source compiles into the shared local HyperionX.Custom.dll. You can hand off reviewable source directly or use the local .hxpkg package workflow added in the signed 1.1.18 release record. Package support does not establish a signed extension or Marketplace distribution contract.

The dialog labels and selection details below match the reviewed 1.1.27 source. Check the documentation version map and your installed build; source verification is not a public-release announcement.

Review source before trusting it

Code Lab extensions execute inside the desktop process. Indicators and strategies can consume account and market context, strategies can route orders, and add-ons can retain process-wide resources. Review the complete source before importing or building it. Package validation does not authenticate its author or make its code safe.

For a manual source handoff, preserve the same categories used by Code Lab. The package exporter creates its own archive layout; send the README and license alongside that package.

MyExtension/
├─ README.md
├─ Indicators/
│  └─ AcmeTrend.cs
├─ Strategies/
│  └─ AcmeTrendStrategy.cs
└─ LICENSE.txt

Include only the folders the extension actually needs. Do not include bin, obj, HyperionX.Custom.dll, a PDB, copied HyperionX assemblies, credentials, logs, account exports, or user settings.

The bundle README should record:

  • Extension name and version.
  • HyperionX version used for verification.
  • Every included public class and its extension category.
  • Required provider capabilities, such as trade ticks, depth, or account access.
  • Whether the extension can submit orders or access the network or file system.
  • Installation, expected-result, update, and removal steps.
  • Known historical, playback, simulation, and live differences.
  • Third-party license and dependency information.

Before sharing​

  1. Give every public class a distinctive name; all recipient sources compile into the same assembly.
  2. Remove dead files, copied generated code, secrets, and machine-specific paths.
  3. Build with the entire custom tree, not an isolated source file.
  4. Run the relevant verification matrix.
  5. Test a second build and reload.
  6. For strategies, verify a LocalPaper account explicitly and document all order-routing settings.
  7. Record the exact HyperionX version used for the final test.

Export a local package​

  1. Open Tools > Export to show Export HyperionX Package.
  2. Select Add, choose one or more items, then confirm the selection. The catalog has Add-ons, Indicators, Strategies, and Risk Templates filters.
  3. If Select Optional Dependencies opens, review the suggested custom source files. Select only what you intend to share, or select none and choose Continue.
  4. Add any desired .hxstrategy.json risk templates separately. A matching template is suggested but is not required or automatically included.
  5. Review the final list, remove unwanted items, then select Export and save the .hxpkg file.

Dependency suggestions come from source references among available catalog items. They are not a complete dependency guarantee or NuGet restore. The reviewed catalog discovers non-generated .cs files directly inside Addons, Indicators, and Strategies; nested folders and other Code Lab categories are not included automatically. Use a documented manual source handoff for those files and test the result on the recipient's custom tree.

A .hxpkg is a ZIP-based local package containing the selected .cs and/or .hxstrategy.json files plus hyperionx-package.json. The reviewed manifest format is version 1; it describes included items, not a guarantee of compatibility with every desktop version. Create packages through the exporter rather than inventing a manifest.

Package validation and trust​

The importer checks the manifest version, listed entries, declared item type and file extension, extraction paths, and size/count limits. Rejected packages report an error before their items are added to the import list. These checks do not verify publisher signatures or review source behavior.

Local Code Lab .hxpkg files are distinct from internal Marketplace .hpxpkg files. Marketplace signing, licensing, publishing, and follower execution do not become supported through this importer. See Marketplace Status.

Install a source bundle​

  1. Read every source file and the bundle README.
  2. Close or stop active instances that the new files will replace.
  3. Check for class-name and file-name collisions in %USERPROFILE%\Documents\HyperionX\Bin\Custom.
  4. Copy each .cs file into its matching category folder.
  5. Open Tools -> Code Lab and build the full custom project.
  6. Complete desktop runtime activation with Compile Project, the intended selector, or a restart.
  7. Fix all diagnostics before enabling any installed extension.
  8. Create a fresh instance in its real host and inspect the HyperionX log.

Copying a file alone does not load it, and a Code Lab-only green build is not activation. The source becomes executable after the desktop runtime successfully compiles, loads, and discovers the complete custom assembly.

Using Tools > Import​

  1. Review the source and templates, then stop affected running instances and back up files that may be replaced.
  2. Open Tools > Import, select Browse, and add .hxpkg, .cs, or .hxstrategy.json files. A valid package expands into individual rows.
  3. Review every row and its detected type. Check unwanted rows and select Remove: the checkboxes select rows for removal, while Import processes every row left in the list.
  4. Select Import. For a filename conflict, Yes replaces that file, No skips it, and Cancel stops the remaining import.
  5. Read the summary and resolve compile diagnostics. A source import triggers a full custom-project compile; a template-only import does not compile or install the template's referenced strategy.
  6. Create a fresh instance and complete the runtime checks described above before enabling it.

Source files are copied to the detected category under the configured custom project, while risk templates go to Documents\HyperionX\Templates\Strategies. The reviewed detector recognizes generated Strategy and Indicator aliases as well as their base classes. Still review the category, especially for helper-only files or custom inheritance; use manual placement when the detected destination is unsuitable.

Import is not transactional. Cancelling partway through or encountering a compile failure does not roll back files already copied. Folder placement also does not sandbox the code or exclude it from the shared custom build.

Reviewed 1.1.27 source: bundled-file synchronization

The reviewed synchronizer installs missing product-bundled files even when the custom folder is not empty. It updates an unchanged product-managed file in place, but preserves a user-modified file and writes the incoming version beside it with an .hpx-update suffix. Ownership hashes are stored in .hyperionx-bundle-state.json at the custom-project root.

Compare and merge an .hpx-update file deliberately, then build the complete project; the preview is not active merely because it exists. Do not edit or delete the ledger as a routine update step. Verify this behavior in the installed build using the version map, and confirm required Preview modules on each target installation.

Update safely​

  1. Disable running strategies before the build and remove affected instances from their hosts.
  2. Keep a recoverable copy of the extension's currently working source files.
  3. Replace only files owned by that extension.
  4. Build the entire custom project and correct any conflicts.
  5. Recreate affected instances after the successful build. Do not rely on toggling a strategy that remained enabled during the build; remove and add it again or reload its owning host.
  6. Repeat the extension's expected-result and safety checks.

An add-on reload calls OnUnload() only for an instance whose earlier OnLoad() succeeded. A new add-on must also roll back partial acquisition inside a failing OnLoad().

Remove safely​

  1. Stop strategies and remove affected indicators from active charts.
  2. Move only the extension's owned .cs files outside the Custom tree.
  3. Build again so HyperionX loads an assembly without those types.
  4. Confirm add-ons unloaded and the extension no longer appears in selectors.
  5. Restart HyperionX if faulty in-process code left resources active.

Do not delete shared support files or another extension's sources. A failed Code Lab pass can leave the earlier runtime objects active, while a failed desktop runtime compile can occur after the old custom assembly was unloaded. Resolve the error, complete runtime activation, and verify selectors/logs before considering removal complete.

Dependency boundary​

Code Lab does not restore a per-extension project or general NuGet dependency graph. A source bundle should use the .NET and HyperionX references already supplied to Code Lab. If a feature needs independent packages, process isolation, or a separately deployable service, build an external application and communicate through the documented local desktop API.

Current distribution limits​

Local source packages do not provide a supported public contract for:

  • Publisher-authenticated Code Lab archives or manifests.
  • Binary-only Code Lab distribution.
  • Automatic dependency restoration.
  • Transactional install, rollback, or uninstall.
  • Marketplace validation or licensing hooks.

Use the supported local exporter or an explicit source handoff. Keep a recoverable copy of replaced files, and do not treat the package's format version as a signature, compatibility certification, or Marketplace approval.

Continue with API Status and Compatibility, Build, Test, and Debug, and HyperionXScript Best Practices.