Deployment

Apache Ignite.NET consists of .NET assemblies and Java jar files.
.NET assemblies are referenced by your project and are copied to output folder during the build automatically.
Jar files should be copied manually. Ignite.NET discovers them via IgniteHome or JvmClasspath settings.

Full Binary Package Deployment

• Copy whole distribution package contents as downloaded from https://ignite.apache.org along with your application
• Set IGNITE_HOME environment variable or IgniteConfiguration.IgniteHome setting to point to that folder

NuGet Deployment

Post-build event is updated automatically during Ignite.NET NuGet package installation to copy jar files to Libs folder in the output directory (see Getting Started). Make sure to include that Libs folder when distributing your binaries.

Make sure IGNITE_HOME is not set globally. Normally you don't need to set IGNITE_HOME with NuGet, except for ASP.NET deployments (see below).

if not exist "$(TargetDir)Libs" md "$(TargetDir)Libs"
xcopy /s /y "$(SolutionDir)packages\Apache.Ignite.1.6.0\Libs\*.*" "$(TargetDir)Libs"

Custom Deployment

Jar files are located in libs folder of the binary distribution and NuGet package.
Minimum set of jars for Ignite.NET is:

• ignite-core-{VER}.jar
• cache-api-1.0.0.jar
• ignite-indexing folder (if cache queries are used)
• ignite-spring folder (if spring configuration is used)

Deploying jars to a default location:

• Copy jar files to a Libs folder next to Apache.Ignite.Core.dll
• Do not set IgniteConfiguration.JvmClasspath, IgniteConfiguration.IgniteHome properties and IGNITE_HOME environment variable

Deploying jar files to an arbitrary location:

• Copy jar files somewhere
• Set IgniteConfiguration.JvmClasspath property to a semicolon-separated string of paths to each jar file
• Do not set IGNITE_HOME environment variable and IgniteConfiguration.IgniteHome property

c:\ignite-jars\ignite-core-1.5.0.final.jar;c:\ignite-jars\cache-api-1.0.0.jar

ASP.NET Deployment

JvmClasspath or IgniteHome have to be explicitly set when using Ignite in web environment (IIS and IIS Express), because dll files are copied to temporary folders, and Ignite can not locate jar files automatically.

You can set IgniteHome like this in ASP.NET environment:

Ignition.Start(new IgniteConfiguration
{
    IgniteHome = HttpContext.Current.Server.MapPath(@"~\bin\")
});

Alternatively, IGNITE_HOME can be set globally. Add this line at the top of the Application_Start method in Global.asax.cs:

Environment.SetEnvironmentVariable("IGNITE_HOME", HttpContext.Current.Server.MapPath(@"~\bin\"));

Or, you can use the following method to populate JvmClasspath:

static string GetDefaultWebClasspath()
{
    var dir = HttpContext.Current.Server.MapPath(@"~\bin\libs");

    return string.Join(";", Directory.GetFiles(dir, "*.jar"));
}

IIS Application Pool Lifecycle, AppDomains, and Ignite.NET

There is a known problem with IIS: when web application is restarted (due to code changes or a manual restart), application pool process remains alive, while AppDomain gets recycled.

Ignite.NET automatically stops when AppDomain is unloaded. However, new domain may be started when old one is still unloading. So the node from old domain can have an IgniteConfiguration.IgniteInstanceName conflict with a node from new domain.

To fix this issue make sure to either assign a unique IgniteInstanceName, or set IgniteConfiguration.AutoGenerateIgniteInstanceName property to true.

var cfg = new IgniteConfiguration { AutoGenerateIgniteInstanceName = true };

<igniteConfiguration autoGenerateIgniteInstanceName="true">
  ...
</igniteConfiguration>

This way there won't be a GridName conflict, and nodes from old AppDomains will be stopped eventually.

Issue discussion:
http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/