The archive · Product Ideas · Product decision · 2014–2023
QueryStorm puts a C# IDE, runtime and app store inside Excel as a modern VBA
One developer rebuilt Excel automation on .NET: Roslyn IDE, typed LINQ over tables, DLLs embedded in workbooks, a NuGet-style app store.
QueryStorm
What it had to solve
Excel automation still runs on VBA, which Microsoft is not planning to upgrade; its replacement, Office Scripts, is a sandboxed JavaScript environment aimed at the web version of Excel. A C# developer who had run QueryStorm since 2014 (originally SQL-only) decided that C# was the natural fit and built the successor himself.
How it works
Excel's scripting language VBA has not been modernised, and Microsoft's stated direction is Office Scripts, a sandboxed JavaScript environment aimed at the web version of the spreadsheet. Antonio Nakić-Alfirević, a C# developer, saw that JavaScript could not replace VBA for desktop power users — and that Microsoft, committed to JavaScript, was unlikely to enter what he called the 'lucrative C# in Excel market' himself.
QueryStorm had been his project since 2014, originally SQL support inside Excel; over the years he added C# scripting, custom functions, NuGet, a debugger and an app store. The technical core is deliberately modern: Microsoft's Roslyn compiler powers editing, completion and error highlighting; every Excel table gets an auto-generated strongly typed class, making tables queryable with LINQ as if they were in-memory collections; custom data contexts add column types and relationships on top.
Distribution is the second half of the idea. Compiled 'workbook apps' are embedded inside the workbook itself, so a finished tool travels as an ordinary .xlsx file that the free 4MB QueryStorm runtime can run. Extensions go further and are distributed through NuGet-style repositories, with a built-in app store plus self-hosted options for teams, so a C# developer can publish an Excel feature the way they publish a library.
Why it lands
- Roslyn turns the hard part — a full C# editing experience — into a library the add-in can surface, so one developer can ship an IDE without writing a compiler.
- Auto-generated types for tables reframe Excel as a typed data source, letting users think in LINQ queries instead of cell coordinates.
- Embedding compiled DLLs in the workbook makes the unit of distribution the file itself, which is how Excel users already share work.
- A free runtime plus self-hostable repositories created a distribution channel that did not depend on Microsoft's add-in store.
- Starting with SQL in 2014 let the author learn the Excel integration problem before betting years on the C# layer.
What it did
The Show HN on 25 January 2023 drew 670 points and 179 comments. Developers called it 'very, very useful', said LINQ suits data munging better than JavaScript, asked about the Excel-DNA/VSTO architecture, and one recognised the project from years earlier, when it went by the name ThingieQuery.
What you can take
When a platform owner abandons its power-user language, the gap is open to whoever builds on the platform's own data model and compiler infrastructure — the result feels native, not bolted on.
Since then
The essay stayed live as the product's main introduction, and the launch thread records the reception: developers debated whether Excel should ship LINQ natively, whether F# deserved the same treatment, and how the Excel-DNA runtime and VSTO IDE were assembled, with the author answering each. The free runtime remained the entry point for running workbook apps, while extension authors could register their own repositories or rely on the built-in one — a distribution model QueryStorm kept rather than handing to a marketplace.
Sources
- Show HN: I've built a C# IDE, Runtime, and AppStore inside Excel
- QueryStorm | C# in Excel — Replacing VBA with C#?
spotted an error? The archive wants to know.
Your turn
You just read one. Describe the brief you are staring at, and see who has been given the same problem.
Free account · 3 free questions · no card