Skip to main content

Share and Deploy Extensions

HyperionX 1.1.10 loads one locally compiled HyperionX.Custom.dll; it does not yet expose a signed, versioned extension-package or marketplace contract. The supported handoff is therefore a small, reviewable source bundle that the recipient places in the Code Lab custom tree and builds locally.

Treat every source bundle as trusted code

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 building it.

Preserve the same categories used by Code Lab:

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.

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​

The desktop import dialog copies selected .cs files into a category folder and then compiles the complete custom project. In 1.1.10 its label detector recognizes direct StrategyBase, IndicatorBase, BarTypeBase/IBarBuilder, and AddonBase declarations. A normal public script inheriting the generated Strategy or Indicator alias can therefore be labeled Addon even though runtime discovery still follows its actual namespace and base type.

Review the detected category before importing. For a multi-file bundle, manual placement using the layout above is more predictable. Folder placement is organizational; it does not sandbox the code or remove it from the atomic custom build.

Candidate bundle synchronization

The active release-candidate 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. This candidate behavior still requires verification with the exact clean, signed installer, so confirm required Preview modules on every 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​

HyperionX 1.1.10 does not document a public contract for:

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

Do not invent those formats in a customer bundle. Treat them as future platform capabilities and keep the 1.1.10 handoff source-based, explicit, and reversible.

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