Ignite.NET is built on top of Ignite and provides native APIs for .NET developers. Source code is in modules/platforms/dotnet folder.


For Linux instructions see below.

  • .NET Framework 4.0+ or .NET Core 2.0+
  • JDK 8
  • Apache Maven

Getting Started On Windows

Install software

  1. Install Java JDK 8.x:
  2. Set JAVA_HOME environment variable to point to the JDK installation directory (something like "C:\Program Files\Java\jdk1.8.0_111")
  3. Download and unzip Apache Maven to some folder:
  4. Add Maven bin folder to PATH environment variable (example: "c:\Programs\Maven\apache-maven-3.3.9\bin\")
  5. Install latest Visual Studio (free Community Edition will do).

Get source code

For more details on working with GitHub forks and pull requests see How to Contribute OLD#GitProcess

Build Java sources

  1. Change to modules\platforms\dotnet directory
  2. Run build.bat -skipDotNetCore

When doing pure .NET development, you only need to run this every time you update your branch from master.

Build .NET sources

  • Open modules\platforms\dotnet\Apache.Ignite.sln in Rider or Visual Studio
  • Build solution

Running Unit Tests

Ignite.NET uses NUnit for unit tests. You can run them with ReSharper right away, or with NUnit Test Adapter for Visual Studio.

  • Make sure to disable assembly shadow copy in unit test runner settings

Running Tests On TeamCity

  • Ignite uses TeamCity-based continuous integration:
  • If you do .NET-only development, you are interested only in test suites having "Platform.NET" in the name
  • Create an account to be able to start new runs
  • .NET NuGet suite can be used to produce release NuGet binaries (see Artifacts tab of a finished build)

Getting Started on Linux and macOS

Ignite.NET can be built, developed, and tested on Linux and macOS with .NET Core. See Apache.Ignite.DotNetCore.sln.


Getting started

  • Get code: git clone
  • Change to .NET directory: cd modules/platforms/dotnet
  • Build Java and .NET: ./
  • Run all tests (takes a while): cd Apache.Ignite.Core.Tests && dotnet test -p Apache.Ignite.Core.Tests.DotNetCore.csproj
  • Run specific test: dotnet test -p Apache.Ignite.Core.Tests.DotNetCore.csproj --filter CacheTest
  • IDE: Open Apache.Ignite.DotNetCore.sln

General Guidelines

  • Do not break public APIs
    • Do not rename or change existing public APIs in any way - users should be able to upgrade to a new minor version (see SemVer) and their app should keep working
    • Be very careful when adding new public APIs. Public API changes must go through a review by maintainer
    • Pay attention to access modifiers
      • All types within Impl folder should be internal
      • All other types are public and, therefore, are part of public API
  • Tests are required. We strive to cover all imaginable use cases:
    • Happy path: test that API works as expected when provided with good input
    • Bad user input: test that bad method arguments result in ArgumentException, use IgniteArgumentCheck class
    • Other illegal state situations (e.g. get a cache that does not exist): test that resulting exceptions are user-friendly and contain information on how to fix the issue

Coding Guidelines

  • Ignite.NET follows standard MSDN Framework Design Guidelines in regards to naming, project and namespace structure, type design, etc.
  • Private fields should be _underscoreCamelCase (this is not covered by guidelines above)
  • Non-private instance fields are not allowed
  • Line length should not exceed 120 characters

Coding guidelines compliance is checked by .NET Inspections TeamCity suite (see below).

Static Code Analysis

Three code analysis tools are integrated with Ignite.NET project:

All these tools assume that project has been built in Debug Any CPU mode.

Building Release Binaries

There is a build.ps1 file in modules/platforms/dotnet folder. This build script performs end to end build, including Java, .NET and NuGet.

To build everything and produce release binaries (in bin folder) and NuGet packages (in nupkg folder), run the script without arguments.

Run `Get-Help .\build.ps1 -detailed` PowerShell command to view detailed build script documentation.

  • No labels