Decompiling an Excel template into a script - #4 JSON

This is the JSON counterpart to the XSLT walkthrough, the last of this four-part series, but the story is slightly different. XML pairs naturally with a declarative transform language (XSLT). JSON doesn’t really have an equivalent standard — there’s no dotnet-tool-shaped “jq for .NET” to lean on. So instead of a transform engine applied to a data file, this demo is just what a JSON pipeline naturally looks like in practice: a plain script that already emits JSON, wired straight into fsopenxmldsl-mcp build. The full project is on GitHub: Kookerella.Demo.DecompileToSource.

What we’re starting from

The same plain Excel file used in the other three demos: a bold, 16pt “INVOICE” title, a white-on-navy header row with a bottom border, and two sample line-item rows with an Amount column computed as Qty * Unit Price.

Step 1: Install the tool

dotnet tool install -g Kookerella.FsOpenXmlDsl.Mcp

Step 2: Reverse-engineer the template

fsopenxmldsl-mcp convert templates/InvoiceTemplate.xlsx --lang json -o decompiled/InvoiceTemplate.json

This prints out plain JSON — not source code, just the workbook’s own data and styling, validated against the tool’s own Json.schema.json schema. A trimmed excerpt, the “Widgets” row:

{ "ref": "A4", "text": "Widgets" },
{ "ref": "B4", "number": 3 },
{ "ref": "C4", "number": 9.99, "style": { "numberFormat": "currency" } },
{
  "ref": "D4",
  "formula": { "expression": "B4*C4", "cachedValue": 29.97 },
  "style": { "numberFormat": "currency" }
}

Text, numbers, a formula with its cached value, and styling — all as plain JSON, no code to read.

Step 3: Turning the decompiled snippet into a generation script

The decompiled JSON is disposable — it’s the starting point, not the deliverable. The maintained version is split across two files: orders.json (the data that varies invoice to invoice) and build.ps1 (reads orders.json, builds the workbook JSON — the styling objects copied verbatim from the decompiled file, as PowerShell [ordered] hashtables — and writes it out).

The diff from the decompiled file is deliberately small — the title cell and the four header cells are the exact same shape as the decompiled JSON, just written as PowerShell hashtables instead of raw JSON. Only the two hardcoded “Widgets”/“Gadgets” objects became this loop:

for ($i = 0; $i -lt $orders.Count; $i++) {
    $order = $orders[$i]
    $row = 4 + $i
    $amount = [double]$order.quantity * [double]$order.unitPrice

    $cells += [ordered]@{ ref = "A$row"; text = $order.item }
    $cells += [ordered]@{ ref = "B$row"; number = $order.quantity }
    $cells += [ordered]@{ ref = "C$row"; number = $order.unitPrice; style = $currencyStyle }
    $cells += [ordered]@{
        ref     = "D$row"
        formula = [ordered]@{ expression = "B$row*C$row"; cachedValue = $amount }
        style   = $currencyStyle
    }
}

This is the plain-script mirror of the C# demo’s collection-expression spread, the F# demo’s yield!, and the XSLT demo’s xsl:for-each — same idea (build one row per order), a fourth different way to express it, this time with no special language feature at all, just an array and a loop.

[ordered]@{...} (rather than plain @{...}) matters here: PowerShell’s built-in hashtable doesn’t preserve key order, and an unordered one would still work (fsopenxmldsl-mcp build doesn’t care about JSON key order) but would make the generated file harder to read and diff against the decompiled reference.

Step 4: Building the Excel file

.\build.ps1

Internally, this serializes the hashtables above with ConvertTo-Json -Depth 10, writes the result to invoice.workbook.json, and then runs:

fsopenxmldsl-mcp build invoice.workbook.json invoice.xlsx

build is the inverse of convert --lang json: it reads JSON matching the tool’s Json.schema.json schema and writes a real .xlsx. No C#, F#, or XSLT was involved anywhere in this pipeline. The only “code” is a short, ordinary script — which is also the point: most real JSON pipelines (a report generator, an API response, a CI job) are already exactly this shape.

Step 5: Prove it stays correct

This pipeline is tested the same way the other three demos are — by running the actual build.ps1 script and inspecting the result, rather than trusting that the script “looks right”:

• Schema validity — runs a real OpenXmlValidator over the output.
• Correctness — feeds in 0, 1, and 3 orders and checks the row count and the Amount formula for each one.
• Styling preservation — pins the exact colors, bold, font size, and border style that came from the original template.

Recap

Four languages, one template, one idea: decompile it once, then keep only the two lines that actually change. See the FsOpenXmlDsl and MCP server product pages for the libraries behind all four.