Apache Ignite.NET 2.4: Thin and cross-platform

Recently a new version of Apache® Ignite™ was released. Let’s examine some of the new features from the .NET perspective.


Ignite Cluster

Thin .NET Client


Before Apache Ignite version 2.4 (in both Java and .NET), there were two cluster connection modes: Server and Client. Basically, the difference between the client mode and server mode boils down to the following: the client nodes don’t store data and do no computations (compute, map-reduce). Otherwise, already present components (discovery & communitaction[O1] ) are reused. Adding a client node to the cluster is a relatively heavyweight process, and it may run for several seconds.


The .NET case was further complicated because we started the JVM inside this process, consuming plenty of resources and introducing additional requirements to the environment.


All of these issues are solved with our new "Thin client," which:

  • Instantly connects to one of the server nodes via socket.
  • Does not require that Java be installed on the machine, nor starts the JVM.
  • Consumes little if any memory.
  • Connects to any type of Ignite node: Java-only, .NET, C++.

Currently only Cache + LINQ functionality has been implemented, but we plan on adding everything else in the future. That said, the API remains the same:


We should note that the emergence of a Thin client doesn’t mean that the present "rich" API will be dismissed in the future:

  • The Thin client will always remain somewhat slower than the rich one, because the former relies on a proxy.
  • Many features, such as Compute and Services, work on server nodes via the Rich API (even if front-end[O2]  is the caller).

LINQPad example

Working with Ignite, one may want to quickly connect to a cluster, look up data in caches, and run some query or queries. To do this, you may use such tools as Visor Command Line and Web Console.


With a Thin client in place, all of this may be quickly and conveniently achieved via LINQPad. Just add the NuGet package Apache.Ignite with "Add NuGet...", and a ready code example will be loaded automatically.



.NET Core, Mono, Linux, macOS


Ignite.NET in Visual Studio Code on macOS


The header is self-explanatory: now you can use Ignite.NET on the following platforms and OS:

  • Windows (.NET 4.0+, .NET Core 2.0+, Mono)
  • Linux (any distribution, which supports .NET Core 2.0+ or Mono)
  • macOS (again, under .NET Core 2.0+ or Mono)

How to try it out?

Under .NET Core, the readme is the same for all platforms:

  • dotnet new console
  • dotnet add package Apache.Ignite
  • In Program.cs add Apache.Ignite.Core.Ignition.Start();
  • dotnet run

warning NU1701: This package may not be fully compatible with your project.


The project assembly raises a warning: warning NU1701: Package 'Apache.Ignite 2.4.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.


This happens because we have a single dll inside the NuGet package, assembled under .NET 4.0, to simplify the workflow. It works entirely fine under .NET Core. You can suppress this warning with the line <PropertyGroup><NoWarn>NU1701</NoWarn></PropertyGroup> in the csproj file.



Mono works with plain 'Classic .NET' solutions, which can be created under Linux in MonoDevelop.


One of the use cases for Mono embraces 32-bit processors, because .NET Core requires x64. I ran into this by testing Ignite.NET startup, so I reached a vintage EEE PC 901 with Lubuntu installed, and everything started under Mono just fine.


Development under Linux and macOS

Now it’s possible not only use Ignite.NET, but also develop with it for Linux and macOS. Under Mono, the main solution compiles as is. Under .NET Core we added a special solution and project files under .NET Core:



Ignite.NET 2.4 now embraces all of the major platforms and operating systems. One of the more vibrant use cases involves a cluster of.NET nodes, run under Linux, and front-end applications, working via Thin protocol on workstations[O3]  running Windows.


We have further developments on the roadmap for the .NET Core domain: integration with ASP.NET Core (caching) and Entity Framework Core (caching, data provider). Such integrations already exist for classic ASP.NET and EF.