How to Debug a SyteLine IDO Extension Class in Visual Studio
How do I debug a SyteLine IDO extension class in Visual Studio
Also searched as
- syteline extension class breakpoint never hit
- attach visual studio to idoruntime
- debug mongoose extension dll csi
- syteline custom business logic not firing
Short answer
SyteLine IDO extension classes run inside the server-side IDO runtime, not inside Visual Studio, so breakpoints only hit once you attach the debugger to that process and deploy matching PDB files. Attach to IDORuntime.exe on classic installs or to the w3wp.exe worker process on IIS-hosted CSI, build in Debug configuration, and copy the DLL and PDB together before setting breakpoints.
Applies to: SyteLine 8.x, 9.x, CloudSuite Industrial (CSI) 10.x, on-prem and IIS-hosted deployments
Attach Visual Studio and hit your breakpoint
- 1Build the extension class project in Debug configuration, not Release, so the PDB carries full symbol and line information.
- 2Copy the compiled DLL and matching PDB into the same bin folder SyteLine loads the extension assembly from, as set on the IDO Collection's Extension Assembly field.
- 3Identify which process hosts the IDO runtime: IDORuntime.exe for classic client-server installs, or the w3wp.exe worker process for the SyteLine application pool on IIS-hosted CSI.
- 4In Visual Studio use Debug > Attach to Process, check Show processes from all users, and pick the correct IDORuntime.exe or w3wp.exe instance - there may be several app pools running.
- 5Set a breakpoint inside the extension method (BeforeUpdate, AfterInsert, or a custom method override) and trigger the action from the SyteLine client or a test IDO call.
- 6If the breakpoint shows hollow with a warning, confirm the DLL actually reloaded by checking Debug > Windows > Modules, then recycle the app pool or restart the IDORuntime service.
- 7On IIS-hosted CSI, confirm the app pool identity can read the bin folder and that the old assembly is not still locked - recycle the pool before overwriting the file.
Why the breakpoint does not hit
Extension classes execute inside the server-side process that hosts the IDO runtime, not the Visual Studio process you are editing in, so pressing F5 in the class library project does nothing on its own. You must attach to the already-running host process, and the class library that process has loaded must actually be your latest build - a locked or stale DLL still sitting in the bin folder is the most common reason a breakpoint you just added never fires.
A related and very common symptom is the breakpoint appearing as a hollow circle with a warning that no symbols were loaded. That means the PDB either was not copied, or belongs to a different build than the DLL currently loaded in the process. Always deploy the DLL and its PDB together, from the same build, every time.
IIS keeps an assembly loaded in memory for the life of the application pool, so simply overwriting the file on disk is not enough - the pool has to recycle (or the IDORuntime service has to restart on classic installs) before the new build is actually picked up and its symbols become valid.
Locating the right process to attach to
On classic client-server SyteLine, extension logic runs inside IDORuntime.exe. On IIS-hosted CloudSuite Industrial, it runs inside a w3wp.exe worker process tied to a specific application pool. A server can be running several app pools at once - for different sites, tenants, or environments - so picking the wrong w3wp.exe is a common reason nothing seems to happen when you attach.
In IIS Manager, or from Task Manager's Details tab with the App Name / Command Line columns enabled, you can match a w3wp.exe process ID to the application pool name that serves the SyteLine site instance you are actually testing against before you attach.
Extension class override points worth breakpointing
Typical override points include before/after row events on insert, update, and delete, and the invoke handling used by custom IDO methods. These are the places validation, defaulting, and integration side effects usually live, so they are the natural first stop when behavior does not match expectations.
Attaching a live debugger is reasonable in a dev or test environment, but risky against production - a paused thread inside a breakpoint can look to end users like SyteLine has frozen. For production diagnosis, write to a log file, the Windows Event Log, or a diagnostic table from inside the extension instead of attaching a debugger to the live process.
Working with a clustered or load-balanced environment
When CSI is deployed across multiple web or app servers behind a load balancer, the request you trigger from the client may not land on the server you attached Visual Studio to, so the breakpoint never fires even though the code path is correct. Pin your test session to a single node - through a direct server URL, a sticky-session setting, or by temporarily taking other nodes out of rotation - before you conclude the extension itself is broken.
Common pitfalls
- !Building in Release configuration - the compiler strips or reorders code so breakpoints land on the wrong line or never bind.
- !Forgetting to copy the PDB alongside the DLL, or copying a PDB from a different build than the DLL that is actually loaded.
- !Not recycling the app pool (or restarting the IDORuntime service) after deploying a new build, so the old assembly stays loaded in memory.
- !Attaching to the wrong w3wp.exe when several application pools run on the same IIS server.
- !Debugging directly against production - a paused thread can appear to end users as SyteLine freezing.
- !Assuming the extension class is wired up at all - if the IDO Collection's Extension Assembly or Extension Class field is blank or wrong, the class never loads regardless of how you debug.
How an ERP-grounded AI assistant handles this
SyteRay indexes IDO Collection metadata - which extension assembly and class each IDO points to - alongside the compiled source, so when an extension class stops firing an agent can check first whether the wiring is even correct before anyone reaches for a debugger. For code confirmed to be wired up but behaving unexpectedly, it can trace the override chain and point at the method most likely responsible from a failed operation's stack, cutting the time spent guessing which of several before/after hooks actually fired.
Frequently asked questions
Why does my breakpoint show as a hollow circle with a warning?
Visual Studio could not find matching symbols for the loaded module. Rebuild in Debug configuration, redeploy the DLL and its PDB together, and confirm the process you attached to actually reloaded the new assembly by recycling the app pool or restarting the IDORuntime service.
Can I debug an extension class in a production environment?
Technically yes with access, but a paused debugger blocks the thread it is attached to and can make SyteLine look frozen to other users on that server. Reserve live debugging for a test or dev instance and rely on logging for production diagnosis.
Where do I find which assembly and class an IDO's extension points to?
Open the IDO Collection record for that IDO and check the Extension Assembly and Extension Class fields - they name the DLL and the fully qualified class SyteLine loads to run your custom logic against that IDO.
My extension class works in the client but not through a web service call - why?
Both paths go through the same IDO runtime, but if your CSI environment load-balances requests across multiple app servers, the call may be hitting a node where the updated assembly was not yet deployed or the pool was not recycled.
Do I need to attach separately for each IDO I am testing?
No - once you attach to the correct IDORuntime.exe or w3wp.exe process, breakpoints in any loaded extension class DLL for that process will hit, regardless of which IDO triggers them.
Related
How to Add Custom Business Logic to a SyteLine IDO with an Extension Class
SyteLine lets you add validation, defaulting, and side-effect logic to any IDO without touching Infor's generated code, by writing an IDO extension class in C# and hooking into the object's Before/After events. The extension assembly is compiled, deployed next to the IDO Runtime, and picked up once the runtime cache is refreshed.
AdvancedHow to Add a Custom Method to a SyteLine IDO in C#
Custom IDO methods let you expose new server-side business logic - beyond the standard Load, Update, and Delete - as a named, callable operation from the SyteLine client, a script, or an external integration. You declare the method and its parameters on the IDO Collection, then implement it in an extension class that handles invoke calls for that method name.
AdvancedHow the SyteLine Event System Works for Workflow Notifications
SyteLine's Event Manager lets administrators subscribe to IDO-level events, such as a purchase order being released or a customer credit hold being set, and fire an email, a Mongoose script, or a workflow action without writing an IDO extension. Cloud tenants can extend the same triggers into ION Workflow for multi-step, cross-application approval processes.
AdvancedHow to Improve SQL Server Performance for a Slow SyteLine ERP System
Most SyteLine performance complaints trace back to a handful of SQL Server issues: stale statistics, missing indexes on high-churn IDO tables, blocking caused by the default isolation level, and IDO Runtime connection pool exhaustion. Working through those systematically, with DMV evidence, resolves the majority of slow system tickets faster than guessing at application-layer causes.
Error fixFixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixDiagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
AI for ERPAn Air-Gapped Private LLM for SyteLine, Built for Defense Suppliers
Deploy a private LLM on an air-gapped network alongside Infor SyteLine for defense suppliers: no internet egress, ITAR and CMMC-aware architecture.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.