DEV Community: Fedi Soltani

Protecting Desktop Software: Hardware Fingerprinting and Heartbeat

Fedi Soltani — Thu, 20 Aug 2026 13:44:18 +0000

How to tie a licence to a machine, verify it continuously, and cut access the moment it stops being valid.

A business plugin sold to a few dozen engineering firms raises a problem web applications never face: it runs on the customer's machine, out of the server's reach. Nothing technically prevents copying it onto ten workstations.

The approach taken ties the licence to the machine rather than the user. On first launch, the plugin builds a fingerprint from hardware and system elements — MAC address, Windows information, installation coordinates — and sends it to a REST verification API. The server maps that fingerprint to a licence and returns a verdict.

A single check at startup is not enough: it lets a revoked licence keep working until the next restart, which can mean weeks. A heartbeat mechanism therefore calls the platform at regular intervals. If the licence has been revoked, has expired, or the fingerprint no longer matches, access is cut within the running session.

On the admin side, an ASP.NET Razor Pages interface creates, revokes and tracks licences. It is deliberately plain: the tool serves an internal team, not an online catalogue, and an over-designed interface would have cost time without returning any.

An honest caveat to close on: no client-side protection is unbreakable. A .NET plugin can be decompiled, and a hardware fingerprint can be forged by someone determined. The realistic goal is not to make copying impossible — it is to make it more expensive than buying, and to give the vendor a way to revoke a licence.

I write more of these at my technical notes — multi-tenant isolation, optimistic concurrency, AutoCAD plugin development, and other things I've actually shipped.

Automating Hydraulic Structure Design Inside AutoCAD

Fedi Soltani — Thu, 20 Aug 2026 13:41:32 +0000

A .NET 8 plugin generating culverts and technical sheets from an alignment and a surface, hydraulic calculations included.

Designing a culvert — the structure that carries water under a road — is repetitive work. The engineer reads an alignment and a surface from the model, computes the geometry, checks hydraulic behaviour, then transfers everything onto a drawing and a technical sheet. The same sequence, dozens of times per road project.

The plugin reads the alignment and surface straight from the drawing through the AutoCAD .NET API, derives the structure's geometry, runs the geometric and hydraulic calculations, then generates the 3D model and the matching technical sheet. What used to take a working session becomes a command.

The most instructive part of the project is not the code: it is the line between what a plugin should compute and what it should delegate. Hydraulic results are exported automatically to HY-8, the US FHWA's reference software, which acts as the verification authority. The plugin does not claim to replace a reference tool — it feeds it clean data and reads back its verdict.

Working with the AutoCAD .NET API imposes constraints web work never raises. The plugin runs inside AutoCAD's process, so an unhandled exception does not fail a request: it takes down the user's session, along with their unsaved work. Transactions against the drawing database must be opened and closed with the same discipline as a SQL transaction.

It is also a useful reminder for a web-oriented profile: the business does not always live in a REST API. Some industries have worked inside a desktop application for thirty years, and the value you add there is measured in engineer-hours freed, not milliseconds of latency.

I write more of these at my technical notes — multi-tenant isolation, optimistic concurrency, desktop licensing, and other things I've actually shipped.

Crossing Five .NET Versions Without Rewriting the Application

Fedi Soltani — Thu, 20 Aug 2026 13:35:46 +0000

From .NET 5 to .NET 10 on production projects: what an upgrade actually costs, and why waiting costs more.

Over three years I have shipped applications on .NET 5, 6, 8 and 10, and led several upgrades on projects already in production. The most consistent lesson is counter-intuitive: the migration is rarely the problem. The waiting is.

Moving a maintained application up one major version generally takes a few days. The same jump on an application left three versions behind becomes a project in its own right, because breaking changes accumulate and compound, and third-party libraries no longer follow the same trajectory.

The approach that worked best is progressive rather than head-on: raise the target framework first, let compiler warnings drive the work, and handle behavioural changes one at a time instead of rewriting. On a government permit management project, the move from .NET 6 to .NET 8 was done exactly that way across the whole solution, with a direct benefit in reduced build and package restore times.

Entity Framework Core deserves particular caution. It is the dependency where behavioural changes are quietest: a query that compiled and ran suddenly produces different SQL, or shifts from server-side to client-side evaluation. Without integration tests against a real database, that class of regression only shows up in production.

Which is, incidentally, the strongest argument for integration tests against a real database under Docker and Testcontainers: they do not only validate today's feature, they make the next upgrade survivable.

I write more of these at my technical notes — multi-tenant isolation, optimistic concurrency, AutoCAD plugin development, and other things I've actually shipped.