Assembly Registration and the IDO Extensions Form
Custom assemblies in SyteLine are registered through the IDO Extensions form (Menu Path: Application > IDO Extensions). Each registration record maps an assembly name to a target IDO and specifies which methods the assembly provides. The assembly DLL itself must be placed in the Mongoose application server's bin directory, typically at [InstallPath]\Mongoose\Server\bin\.
For web client compatibility, a copy must also exist in the IFS application's bin directory. CustomLogic), the class name implementing IDOExtensionClass, and the target IDO. After registration, restart the Mongoose application pool and the IFS application pool to force metadata cache reload.
- Register assemblies in Application > IDO Extensions with assembly name, class name, and target IDO
- Place DLLs in both the Mongoose Server bin directory and the IFS application bin directory
- Assembly names must match exactly between the registration record and the compiled DLL
- Restart both the Mongoose and IFS application pools after any assembly deployment or update
Versioning Strategy and Dependency Management
NET's assembly resolution mechanism, which means version mismatches cause cryptic FileLoadException or MissingMethodException errors at runtime. dll) at specific versions. When SyteLine is upgraded, these SDK assemblies change versions, and your custom code must be recompiled.
Use assembly binding redirects in the Mongoose server's configuration file to handle minor version changes, but always recompile for major version upgrades. Store all custom assemblies in a dedicated source control repository with a build pipeline that compiles against the target SyteLine SDK version and produces deployment packages with checksums.
- Version mismatch errors appear as FileLoadException or MissingMethodException in the Mongoose log
- Add binding redirects in MongooseRuntime.exe.config for minor SDK version changes between patches
- Always recompile custom assemblies when upgrading between SyteLine major versions (e.g., 10.1 to 10.2)
- Use a CI/CD pipeline that compiles against the exact SyteLine SDK DLLs from the target environment
Multi-Server Deployment and Synchronization
Production SyteLine environments typically run multiple Mongoose application servers behind a load balancer. Every custom assembly must be deployed to every server simultaneously, or users will experience intermittent failures depending on which server handles their request. Build a deployment script that stops each application pool sequentially, deploys the updated DLLs, and restarts the pools with health checks.
Use file hash comparison (SHA-256) to verify that all servers have identical assembly versions. The Mongoose Admin Console's Server Status page shows which assemblies are loaded on each server. For zero-downtime deployments, use a rolling strategy: remove one server from the load balancer, deploy, verify, return it, then proceed to the next server.
- Deploy assemblies to all Mongoose application servers simultaneously to prevent version drift
- Use SHA-256 hash verification to confirm identical assembly versions across all servers
- Implement rolling deployment: pull server from load balancer, deploy, verify, then restore traffic
- Check the Mongoose Admin Console Server Status page to verify loaded assembly versions per server
Try it here, free
SyteLine Customization Technical Debt Scorer
Measure how much upgrade drag, risk, and maintenance cost your SyteLine customizations have accumulated, and learn where to pay it down first.
Need a reliable deployment pipeline for SyteLine customizations? We build automated deployment systems for enterprise SyteLine environments, contact us.