dotless: bringing the Less CSS preprocessor to .NET

Four packages, and the one you probably want is Core

The repository publishes its work as four separate NuGet packages, and choosing the wrong one is the first decision a new user faces.

dotless.Core is the compiler itself. dotless.AspNetHandler is a handler that compiles Less files on the fly inside ASP.NET. dotless.CLI is a command line interface, a console application for compiling Less files. And dotless is a backward compatible package that contains both Core and the ASP.NET handler, and the README is explicit about its status: please upgrade to either dotless.AspNetHandler or to dotless.Core if you don't need ASP.NET stuff.

That recommendation tells you the shape of the project. The metadata package exists for people who installed the old single package years ago and want an upgrade path that does not break their project references. New work should pick one of the three specific packages, and the choice is usually between the core compiler and the ASP.NET handler, depending on whether your Less is compiled at build time or per request.

The description of the whole project is a .NET port of the Ruby Less CSS library. The README phrases the value plainly, giving variables, nested rules and operators to CSS, and pointing at the original Less project for the full story. So the feature set is the one you already know from the Ruby and Node versions, ported to run on the .NET runtime.

The framework support list ends where .NET Framework 4.5.1 begins

Version 1.6 is the point where the supported platform list changed, and the README states it directly. Starting with version 1.6 the supported frameworks are .NET Framework 4.5.1, .NET Framework 4.6.1, .NET Framework 4.7, and .NET Standard 2.0, which covers .NET Core 2.0, Mono 5.4 and .NET Framework 4.6.1 or later.

For anything outside that list, the instruction is blunt: if your application or library does not run on any of these frameworks you have to stick with version 1.5.3. The .NET Standard 2.0 entry is what makes the package usable from modern .NET, and it is the line that separates a supported deployment from a pinned old one.

What the list does not say is anything about .NET 5 and later as a distinct target, and it does not mention .NET 6, 7, 8 or 9. .NET Standard 2.0 is a compatibility surface rather than a runtime, so a modern .NET application consumes it, but a package that only targets .NET Standard 2.0 does not automatically get the newer platform-specific behaviour, and it does not say here whether the project was updated to keep pace. The safe reading is that the supported list in the README is the list you should plan against.

The release history reinforces the point without needing to be dated: 1.6.7 fixed an empty response, 1.6.5 added support for older framework versions along with bug fixes, and 1.6.3 handled strong name and config fixes. Three maintenance releases, all in 2018.

ASP.NET Core lives in a different repository

If you read the package list and conclude that the ASP.NET handler covers modern ASP.NET, you will be wrong in a way that costs an afternoon. The README handles ASP.NET Core in one line: if you want a handler for ASP.NET Core applications, check out WebOptimizer.Dotless, a separate project hosted by the same maintainer.

That split is the practical limit of this package set. dotless.AspNetHandler targets the classic ASP.NET stack, which is the framework family the whole package list is built around. A team on ASP.NET Core has a separate choice to make, and the documentation points at the other project rather than claiming parity.

The naming here is worth pausing on, because there is a trap for anyone who greps for a handler package. The package called dotless.AspNetHandler is the classic one, and the ASP.NET Core answer is not in this repository at all. Anyone documenting your build for a colleague should name the package and the target framework together, not just say the handler.

For a server-side rendered application that compiles Less on request, the handler package removes the build step entirely. For a pipeline that precompiles assets once, dotless.Core or the CLI does the same job at build time and fits a lot more naturally into a CI script.

Taking a DLL from the CI artifacts instead of NuGet

For people who do not want the source and simply need a DLL, the README gives two routes.

The first is the GitHub downloads page, where the instruction is to select the latest successful build and open the Artifacts section, where you find the latest compiler executable and any DLLs required. That is a CI artifact rather than a released package, which is an important distinction for a library you are about to depend on. The AppVeyor build status badge at the top of the README points at the same continuous integration system, and the repository has a build.bat, build.sh, build.ps1 and a build.cake file, so Cake is the build script layer, with per-platform wrappers around it.

The second route is the dotless.Core NuGet package, which is the better default for most people because a package reference gives you version pinning and dependency resolution rather than a file you drop into a folder.

The repository also carries how-to-build.md, and the build scripts live alongside a dotless.sln solution file, with src/ and tests/ directories, a nuspec/ directory for packaging, a lib/ directory, tools/, and a samples/ directory containing a sample web application. So the source layout follows the usual .NET conventions, with the extra build tooling that a project supporting three platforms tends to accumulate.

Maintenance is the deciding factor, not features

The last push to the repository was on 2026-05-22, and the project is not archived. The most recent published releases are 1.6.7 from 2018-08-08, 1.6.5 from 2018-07-25 and 1.6.3 from 2018-04-30, and the repository publishes no releases after those.

The gap between a repository that still receives commits and a set of packages that last shipped in 2018 is the central fact about this project. Commits in a repository this old are usually small, they are often to readme files or build scripts, and they do not produce new NuGet versions by themselves. Whether a new dotless.Core package exists on NuGet at a version beyond 1.6.7 is not something this repository states, and the version badges in the package table point at whatever is published there rather than at the source tree.

So the honest way to evaluate dotless is not to ask whether it compiles Less correctly, which it evidently did, but to ask what happens when a Less feature you need appears in the upstream project and does not appear here. The port is a translation of a moving Ruby and JavaScript library, and every feature gap is a gap that stays until somebody ports it.

The licence is Apache-2.0, with a license.txt file in the tree, which is permissive enough that the licensing is not the constraint. Time and platform support are.

The community channel is a Gitter room, and a Gitter room is itself a signal about the age of the project's social infrastructure.

Editorial conclusion

Adopt dotless if you have a .NET codebase that already has Less stylesheets and no working route to a Node-based build, and if you can live with a preprocessor whose last published release was 1.6.7 in 2018. Do not adopt it for a new project where you can choose a maintained toolchain, since the package set is legacy and the ASP.NET story splits across a separate project for ASP.NET Core. Before you commit, check the .NET Framework version of your application against the supported list, which starts at 4.5.1 and includes .NET Standard 2.0, confirm whether you need the ASP.NET handler or only the core compiler, and read the how-to-build.md file in the repository if you plan to build from source rather than take the NuGet package.

Frequently asked questions

Official sources

1. dotless/dotless on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases