# How to Debug a SyteLine IDO Extension Class in Visual Studio > Source: https://netray.co/erp-help/syteline-debug-mongoose-extension-class-visual-studio > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind advanced ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module Customization - IDO Extension Classes ## Query How do I debug a SyteLine IDO extension class in Visual Studio ## Alternate Queries - syteline extension class breakpoint never hit - attach visual studio to idoruntime - debug mongoose extension dll csi - syteline custom business logic not firing ## Applies To SyteLine 8.x, 9.x, CloudSuite Industrial (CSI) 10.x, on-prem and IIS-hosted deployments ## Steps ### Attach Visual Studio and hit your breakpoint **Items:** Build the extension class project in Debug configuration, not Release, so the PDB carries full symbol and line information. Copy 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. Identify 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. In 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. Set 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. If 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. On 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. ## Sections ### Why the breakpoint does not hit **Body:** 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 **Body:** 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Why does my breakpoint show as a hollow circle with a warning? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms syteline debug extension class, attach visual studio syteline, idoruntime.exe debug, w3wp.exe syteline debug, syteline breakpoint not hit, mongoose extension class, csi extension assembly debug, syteline pdb symbols, syteline ido runtime process, debug csi custom code --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json