Web-Based vs Desktop AHU Selection Software: The End of ClickOnce

Every AHU sales engineer has lost an afternoon to this: a customer asks for a re-selection, the laptop is the wrong one, and the selection tool will not install because IT locks down .exe deployment, or because the version on the shared drive is two releases behind the one the factory uses. The engineering is fine. The delivery mechanism is the problem — and for a whole generation of AHU selection software, that mechanism was ClickOnce.

What ClickOnce actually was

ClickOnce is a Microsoft .NET deployment technology introduced with .NET Framework 2.0 in 2005. The idea was reasonable for its era: publish a manifest to a web server, let the user click a link, and have Windows download, sandbox and self-update the application without an administrator running an MSI. For a component supplier shipping a selection program to a few thousand engineers, it removed the entire install-and-patch problem.

Three things have eroded it since:

• Browser launch depends on a shim. ClickOnce originally launched in-browser through Internet Explorer. Chrome dropped NPAPI plugin support in 2015; the Internet Explorer 11 desktop application was retired on 15 June 2022. Microsoft Edge can still launch ClickOnce, but it is a setting an administrator has to allow, not a default behaviour of the open web.
• It is Windows-only, by design. ClickOnce remains supported for Windows desktop applications in modern .NET, but there is no macOS, no Linux, no iPad, no Chromebook. A consultant who works on a Mac cannot open your selection.
• Corporate IT treats it as arbitrary code. Because it is arbitrary code. Application allow-listing, EDR agents and least-privilege desktop policies have all tightened since 2005, and a self-updating executable downloaded from a supplier domain is exactly the pattern those controls exist to stop.

None of that means the underlying selection engines were wrong. It means the wrapper around them stopped matching how buildings are actually designed today — across companies, on borrowed machines, in a browser tab.

Where the vendor DLLs went

The honest objection to browser-native selection software is that the good numbers come from Windows libraries. That is true. Fan, coil, filter and heat-recovery selection engines are shipped by their makers as 32-bit Windows DLLs, and no amount of JavaScript replaces them — evaluating a polynomial fitted to catalogue points is not the same thing as calling the supplier's own engine.

The resolution is not to abandon those libraries. It is to move them off the engineer's laptop and onto a server the engineer never has to think about:

Concern	Installer-based tool	Browser-native, server-side engines
Where the vendor DLL runs	Every user's laptop	One controlled Windows host
Version consistency	Whatever each engineer last installed	One version, identical for everyone
Supplier data update	Re-deploy to every seat	Deploy once, live for all users
Client OS	Windows only	Anything with a modern browser
IT approval needed	Software installation	A URL
Sharing a selection with a consultant	Send files, hope they can open them	Send a link

That is the architecture: the DLLs still do the physics, but they do it once, centrally, behind an API — and the browser is only a client. It also makes the failure modes visible. If a supplier library returns a wrong unit or an out-of-range duty, it is one server log, not a hundred desktops quietly disagreeing.

What the browser buys you beyond deployment

Removing the installer is the boring half. The interesting half is that a browser client can do things a per-seat desktop app never made economic sense for:

• The geometry is live. A 3D model in the tab is the same model the printout, the DXF and the BIM export are derived from, so the dimensions on the drawing cannot drift from the ones on the data sheet.
• A selection is a URL. Sending a project to a colleague, a consultant or the factory is a link, not a versioned file attachment.
• Fixes ship the day they are made. A rounding error in a class boundary — the difference between reporting ECP-05-2026 class A and class B — is corrected once and is corrected for everyone, immediately.
• Compliance logic stays current. Ecodesign and Eurovent requirements move; (EU) 2024/1834 tightens fan efficiency thresholds through 2026–2027. Server-side rules track that without a deployment campaign.

The migration question to ask

If you are evaluating tools, the deployment model is not an IT detail to settle later — it decides who can open your quotes. Ask the vendor three things: what does a consultant need to install to view my selection?, when a supplier updates its data, how long before every user is on it?, and which operating systems are supported today, not on a roadmap? Concrete answers to those tend to sort the field faster than a feature matrix. Our 2026 buyer's checklist covers the rest of the questions worth asking in a demo.

AirSelect3D runs entirely in the browser — no installer, no ClickOnce, no per-seat licence to reinstall — while the real supplier selection libraries run server-side and produce the numbers on the data sheet, the drawing and the DXF.

Open a selection in your browser →