...

Ignite.NET is built on top of Ignite and provides native APIs for .NET developers.

...

...

Source code is in modules/platforms/dotnet folder.

Requirements

...

For Linux instructions see below.

• .NET Framework 4.0+ PowerShell 3or .NET Core 2.0+
• Visual Studio 2010+JDK 8
• Apache Maven

Getting Started

...

Even though Ignite.NET can be developed and run on VS2010 and JDK7, it is more common to use latest Visual Studio and JDK.

...

On Windows

Install software

1. Install Java JDK (not JRE)8.x: httphttps://www.oracle.com/technetworkjava/javatechnologies/javase/javase-jdk8-downloads/index.html
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: https://maven.apache.org/download.cgi
4. Add Maven bin folder to PATH environment variable (example: "c:\Programs\Maven\apache-maven-3.3.9\bin\")
5. Install latest Visual Studio 2017 (free Community Edition will do). Make sure to include C++ stuff.

Get source code

• git clone https://git-wip-us.apache.org/repos/asf/ignitegithub.com/apache/ignite.git

For more details on working with GitHub forks and pull requests see How to Contribute#GitProcessContribute 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.

...

• Open modules\platforms\dotnet\Apache.Ignite.sln in Visual Studio
• Confirm a proposal to upgrade C++ compilers and libraries (you can also do this later by right-clicking the solution in Solution Explorer and clicking "Retarget solution")
• Switch to x64 platform (you don't need AnyCPU for development - it is slower to build and requires x86 JDK installation)
• Build solution

Upgrading C++ compilers and libraries causes two vcxproj files to be modified. You should not commit them, but they get in the way. To fix this, execute the following PowerShell command in the root folder:

• ls *.vcxproj -Recurse | % {git update-index --assume-unchanged $_.FullName}

This command can be reverted by:

• Rider or Visual Studio
• Build solutionls *.vcxproj -Recurse | % {git update-index --no-assume-unchanged $_.FullName}

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.

...

• Ignite uses TeamCity-based continuous integration: http://ci.ignite.apache.org/
• 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

Anchor
linux linux

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

Requirements

• .NET Core SDK 2.0+: https://dotnet.microsoft.com/download
• JDK 8: sudo apt install openjdk-8-jdk
• Maven: sudo apt install maven
• IDE: Rider is recommended.

Getting started

• Get code: git clone https://github.com/apache/ignite.git
• Change to .NET directory: cd modules/platforms/dotnet
• Build Java and .NET: ./build.sh
• 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 (use Editor Guidelines extension https://marketplace.visualstudio.com/items?itemName=PaulHarrington.EditorGuidelines)

Coding guidelines compliance is checked by .NET Inspections TeamCity suite (it runs Visual Studio inspections and ReSharper inspectionssee below).

Building Release Binaries

Solution Platforms Explained

Apache.Ignite.Core.dll assembly includes unmanaged "ignite.jni.dll" as a resource.

AnyCPU build includes two dlls, x64 and x86 (that's why the build takes longer). AnyCPU build requires both x86 and x64 JDK installed.

ignite.jni.dll requires corresponding (x64 or x86) JDK at compile time and JRE at run time.

Ignite.NET loads one of the dlls according to current execution mode (see UnmanagedUtils initializer), and attempts to resolve corresponding JRE using Windows Registry, if the JAVA_HOME variable is not set (IgniteUtils.GetJvmDllPaths).

x64 and x86 solution configurations rely on normal build process where C++ projects are built as dependencies. AnyCPU build, however, uses "build-common.ps1" PowerShell script as a pre-build event of Apache.Ignite.Core project to build C++ parts as both x64 and x86.

...

Static Code Analysis

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

• NDepend: see modules/platforms/dotnet/Apache.Ignite.ndproj. We have 6 build machine licenses (see https://svn.apache.org/repos/private/pmc/ignite/licenses/NDepend.txt, PMC-only access), NDepend is installed on all Windows TeamCity agents and runs as part of .NET Inspections. Report can be seen right there on TeamCity build result page, on NDepend tab.
• ReSharper inspections (come integrated with TeamCity). There are two R# project files in modules/platforms/dotnet/, Apache.Ignite.sln.DotSettings and Apache.Ignite.sln.TeamCity.DotSettings. TeamCity file has less rules enabled, but all of them must pass. Another one is used when you open solution in Visual Studio.
• Microsoft FxCop. Since we officially support Visual Studio 2010, standalone FxCop 1.36 is used, see Apache.Ignite.FxCop in modules/platforms/dotnet/. Later Visual Studio versions have this functionality integrated, this can be enabled with "Run code analysis on build" in project settings.

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 (and build. bat that just calls build.ps1 so you don't have to run PowerShell manually). This build script performs end to end build, including Java, .NET and NuGet. NuGet can be built only in AnyCPU mode (which requires both x64 and x86 JDK installed).

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

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