🧩 Debugging XSLT Made Easy in VS Code: .NET-Based Debugging for Logic Apps

#xslt #logicapps #vscode #azuredatamapper

Debugging XSLT has always been a challenge — especially when you're trying to understand why a transformation doesn't behave as expected. That's why I built XSLT Debugger, a .NET-based Visual Studio Code extension that brings real debugging support for XSLT stylesheets.

🚀 What It Does

This extension lets you:

Set breakpoints in .xslt files
Step through transformations (step over, step into, continue)
Auto-capture XSLT variables — All inline variables appear automatically in the Variables panel
Watch nodes and variables — Add custom watches for XPath expressions and context nodes
Capture and view xsl:message output
Debug with .NET engine (XSLT 1.0, matching Azure Logic Apps) or Saxon (XSLT 2.0/3.0)
Support for msxsl:script C# extensions (step-through skipped for embedded C#)

⚙️ Getting Started

Install XSLT Debugger from VS Code Marketplace
Update .vscode/launch.json with your XSLT and XML file paths
Open your .xslt and .xml files
Press F5 → Start Debugging

That's it — you can now set breakpoints, run step-by-step, and finally see what's happening in your transformations.

📦 Sample files and launch configurations: GitHub Repository

🧩 Why It Matters

This extension brings modern debugging to XSLT development — something that's been missing for years, especially for Azure Logic Apps developers.

Debugging XSLT 1.0 with .NET Engine — Matches Azure Logic Apps production runtime:

Debugging XSLT 2.0/3.0 with Saxon — Variable tracking in action with Debug console, Variables panel, and Watch panel showing inline XSLT variables:

Whether you're maintaining legacy integrations or building new Logic Apps workflows, this extension makes XSLT development finally debuggable.

⚠️ Current Limitations

The debugger is designed to stay simple and stable, focusing on practical debugging scenarios:

No step-back support — Debugging is forward-only; you cannot step backwards or rewind to previous execution states.
Step debugging scope — Step-into works for basic template calls (xsl:call-template). More complex scenarios like xsl:apply-templates with dynamic matching may have limited step-through support.
Variable inspection — Covers @select-based variables and parameters; variables defined with content bodies (e.g., <xsl:variable>...</xsl:variable>) are not yet fully inspected.
Performance overhead — Minor runtime impact in trace modes (~15% slowdown in traceall mode with full XPath value tracking).
Platform-specific packages — Separate .vsix files required for Windows (x64) and macOS (ARM64) due to native .NET runtime dependencies.
XSLT engine support — XSLT 1.0 via compiled engine with inline C# extensions; XSLT 1.0/2.0/3.0 via Saxon.NET engine.
Cannot step into inline C# scripts, though Roslyn instrumentation still logs entry parameters and return values to the console for visibility

These design choices prioritize debugging reliability and ease of use over attempting to instrument every edge case in the XSLT specification.