# NRules for .NET: C# Rules, Rete Matching, and First-Use Setup > NRules is an MIT-licensed rules engine for .NET applications that keeps rule definitions in C# through an internal DSL. It fits teams that want Rete-based rule evaluation without moving business logic out of the .NET codebase, although the README provides only a NuGet installation command and links to external guides. **NRules/NRules** — Rules engine for .NET, based on the Rete matching algorithm, with internal DSL in C#. - Repository: https://github.com/NRules/NRules - Website: https://nrules.net - Stars: 1,653 · Forks: 283 - Language: C# - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/nrules-nrules ## NRules targets rule logic inside .NET applications NRules addresses applications whose behavior depends on changing business conditions, such as combinations of input facts, eligibility criteria, or operational decisions. The repository describes it specifically as a production rules engine for .NET, and its topics include rules, rule engines, C#, DSL, and Rete. It is aimed at developers who want this logic expressed as rules rather than embedding every decision directly in ordinary application code. The defining choice is that rules are authored in C# through NRules' internal DSL. That means the rule source remains inside the .NET development ecosystem, but the README does not document a separate visual editor, external rule file format, or non-.NET DSL. This makes NRules a fit for teams that want rules represented as first-class artifacts while still working in C#. The engine is based on the Rete matching algorithm. The README does not give implementation-level details about token networks, memory nodes, agenda scheduling, or conflict resolution, so those parts should not be inferred from the project name alone. What can be confirmed is that NRules matches rules through a Rete-based design rather than presenting itself as a configuration-only decision table. The repository includes samples named `SimpleRules`, `GettingStarted`, `RuleBuilder`, `JsonRules`, and `DependencyInjection`. Based on these directory names, the project includes examples covering more than one rule-authoring style and at least one dependency-injection setup. The README does not explain their APIs, so those directories are the appropriate files to inspect before deciding whether the available samples match an application's structure. ## NRules connects facts, matching, and C#-authored conditions The documented architecture has three concrete parts: an input model represented as working information, rules written through a C# internal DSL, and matching based on the Rete algorithm. The README does not include a worked data-flow example, but it does establish that C# is the authoring surface and Rete is the matching mechanism. Those two facts separate NRules from libraries that require rules to be loaded from a separate configuration language. The C# DSL is internal. That qualifier matters because it suggests the fluent calls belong to NRules rather than simply being C# statements. However, the exact rule model, condition syntax, binding syntax, action delegate shape, and activation scheduling are not present in the README. The project directs developers to its Getting Started Guide, documentation, API reference, and sample directories for those details. The `JsonRules` sample directory also indicates repository-level coverage for JSON-related rule handling, but the README does not say whether JSON rules are serialized from a live rule session, constructed programmatically, or loaded before execution. Treating that directory as proof of a public JSON workflow would go beyond the documentation. Its contents must be consulted directly to identify supported extension points. Likewise, the `RuleBuilder` directory suggests a distinct sample around programmatic rule construction, but its precise relationship to the internal DSL is not described. This is a useful point to resolve during source review: if the application constructs rules dynamically, determine whether the sample represents a supported public API or a sample-specific technique before adopting it. ## Installing NRules and locating the first working example The README gives one direct installation route through the NuGet package manager. It does not provide a version number in the installation command, platform-specific prerequisites, or a separate command for updating an existing installation. Run this in a .NET project that uses the NuGet package manager: ```console > Install-Package NRules ``` This command adds the `NRules` package through the documented package-manager route. The README does not describe the version that this command selects, so developers operating from a branch or a locked dependency graph should verify the resolved package before copying application code into production. After installation, the README links to the Getting Started Guide as its primary setup resource. It also points to the documentation index, API documentation, and several sample directories. There is no executable first-example command in the README itself. Inventing one would risk introducing unsupported APIs, especially because no rule type, session type, or activation method is shown there. For a first real use, start with the linked Getting Started Guide and use the repository's `samples/GettingStarted/` directory to see how the documented pieces fit together. Compare that code with `samples/SimpleRules/` for the smallest-looking example. If the application uses constructor injection, inspect `samples/DependencyInjection/`. These names guide source inspection, but they do not establish runtime behavior until the linked guide or sample source confirms it. The repository also includes `build.ps1`, `build.sh`, and `build.bat`. The README does not document when to use those scripts or what prerequisites they expect, so they should not be presented as required installation steps for package consumers. They appear in the repository layout, but consumer setup in the README begins with NuGet. ## NuGet setup leaves target-framework compatibility undocumented The short installation section is the largest documentation gap. It says to install `NRules` through NuGet, but it does not list supported target frameworks, required .NET SDK versions, package variants, or dependency constraints. The release information identifies v1.0.4 as the newest listed release on 2026-02-03, but package metadata for that exact version is not included and must be checked in the project's NuGet package. This limitation is concrete. A package that installs does not necessarily fit every existing .NET solution. Before adopting it, compare the resolved package's target framework support with the application's target framework, confirm package compatibility with the project's dependency graph, and inspect the API used by the selected sample. None of those checks can be replaced by the bare installation command. The README also does not discuss whether rules can be unloaded, reloaded, versioned, or inspected at runtime. The existence of `JsonRules` does not settle JSON persistence or deployment behavior. It does not discuss serialization contracts either. For teams with strict release-governance needs, the release list provides concrete versions to track: v1.0.4, v1.0.3, and v1.0.2. The available release listing does not contain release notes for individual changes, compatibility declarations, or migration guidance. Such details should come from the corresponding release and package documentation rather than being inferred from the version numbers. ## NRules differs from configuration-driven decision engines A real alternative approach is to encode business decisions in a configuration-driven rules or decision engine and let application code submit facts to that component. The practical difference is the authoring boundary. NRules documents C# authoring through an internal DSL, while a configuration-driven engine normally expects rules to be maintained outside application source code. That comparison is architectural, not a claim that any particular alternative supports every feature of NRules. This design can suit developers who prefer normal C# tooling, source control, and strongly typed rule-authoring code. It can also make a mismatch for environments where business analysts need to edit rules without compiling a C# application, or where deployed rules must be audited and changed independently of code releases. The README does not say that NRules supports such independent rule deployment, and it does not identify a separate visual editor. Another alternative is to keep the decision logic as conventional C# conditionals or strategy methods. Such code is easier to trace through a debugger and familiar to many .NET developers, but it does not provide NRules' explicit rule organization or documented Rete-based matching. The choice therefore concerns how decisions are represented and evaluated, not simply whether C# is involved. No performance measurements are supplied, so neither Rete nor conventional control flow should be presented as faster in a given application. Adoption should begin with a model of the facts, rules, and expected decisions. If that model aligns with the linked NRules examples and the application's editing model, the C# DSL is a meaningful reason to evaluate it. ## Maintenance and MIT upgrade considerations The repository is not archived, and its last push was on 2026-09-27. Those facts indicate current repository activity, but the README does not provide a support policy, release cadence, compatibility matrix, or long-term-support commitment. Recent releases include v1.0.4 on 2026-02-03, v1.0.3 on 2025-08-14, and v1.0.2 on 2025-03-02. The listed cadence shows several releases across those dates, but it does not promise future releases. NRules is licensed under the MIT license. The repository includes `LICENSE.txt`, and the README attributes copyright to Sergiy Nikolayev for 2012 through 2026. This is a permissive open-source license, but this review does not interpret its legal terms. Organizations still need to review the license file for their own compliance and dependency obligations. Upgrade planning must account for the internal DSL and compiled C# rules. The README does not document migration procedures, deprecation policy, or breaking-change handling, so those topics cannot be assessed from the README. Before changing the package version, inspect the release notes and API changes for the exact target release, then compile the application's rule definitions against it. The package is distributed through NuGet, while repository-level build files and sample projects support development around the engine. Consumers who only install the package should distinguish dependency upgrades from local rule changes. Both need review, but the README supplies no automated compatibility check or formal migration guide. ## The NRules sample collection narrows the evaluation path The repository layout provides a concrete route for evaluating NRules without starting from a blank rule definition. `samples/SimpleRules/` is the most likely place to begin when the goal is to inspect a compact example, while `samples/GettingStarted/` aligns with the README's instruction to use the Getting Started Guide. Their names are confirmed, but their contents and exact APIs are not included in the README. Use the remaining samples selectively. `samples/RuleBuilder/` should be examined for rule construction mechanisms. `samples/JsonRules/` should be examined for the actual JSON boundary and supported workflow. `samples/DependencyInjection/` should be examined if rule dependencies are managed through .NET injection. These samples can answer concrete architecture questions that the README leaves open. The evaluation should also identify what the application expects from its rules. The documentation confirms Rete-based matching but does not state how conflicts are selected when several rules activate, whether activations are synchronous, or how exceptions are handled. Those points can materially affect production use. They cannot be resolved from directory names and should be checked in the guide, API documentation, source, or tests. The strongest reason to continue evaluating NRules is a requirement for C#-authored rules with a Rete-based engine. The strongest reason to stop is a requirement for editor-independent business rule deployment that the README neither documents nor exposes. The repository's sample set is therefore more useful as an acceptance checklist than as proof of untested production behavior. ## Conclusion Application teams that want rule evaluation embedded directly in C# should first review the Getting Started Guide and inspect the included sample projects. Teams that require a visually modeled rule DSL, a documented editor, or deployment instructions beyond NuGet should not adopt NRules based on the README alone. The first decision point is whether its C#-authored rules and Rete-based engine fit the application architecture; the first technical check is whether the current v1.0.4 package and sample projects fit the target .NET environment. ## FAQ ### How do I install NRules for a .NET project? The README directs users to install the NuGet package with `Install-Package NRules`. It does not document required .NET versions or supported target frameworks. ### What programming language is used to write NRules rules? NRules rules are authored in C# using its internal DSL. The README does not describe a separate visual editor or a non-C# rule language. ### Where can I find a working NRules example? The README links to the Getting Started Guide and documentation, while the repository includes `samples/GettingStarted/` and `samples/SimpleRules/`. It does not embed a complete first-example program in the README. ## Sources - [License: MIT](https://github.com/NRules/NRules/blob/develop/LICENSE) - [NRules/NRules on GitHub](https://github.com/NRules/NRules) - [Project website](https://nrules.net) - [README](https://github.com/NRules/NRules/blob/develop/README.md) - [Releases](https://github.com/NRules/NRules/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nrules-nrules