This document is now out of date. New documentation for servicing is being written, and will be published here: http://dotnet.github.io/docs/core-concepts/servicing.html

The servicing mechanism in the KRE allows for patches to be globally applied to a given NuGet package, or the DNX itself.

Overview

At a high level, when the DNX is loading an asset it will check an index file to determine if it should load a patched version instead of what it would normally load. The feature is logically broken up into two components, NuGet package servicing and servicing of the DNX itself.

Package Servicing

Index file

When servicing a NuGet package the index file will contain the following information:

nuget|<package id>|<version>|<original_asset>=<replacement_asset>

  • Type: Will be nuget all lowercase
  • Package id: The name of the package, NuGet Package Id.
  • Version: The version of the nupkg.
  • Original Asset: The path to the assembly being serviced.
  • Replacement Asset: The path to the new assembly. The replacement path would be rooted at the location of the servicing index (see below).

For example:

nuget|Microsoft.AspNet.Http|1.0.0|lib/dnxcore50/Microsoft.AspNet.Http.dll=/packages/Microsoft.AspNet.Http/1.0.0/lib/dnxcore50/Microsoft.AspNet.Http.dll

Mechanism

When loading a package the NuGetDependencyResolver needs to locate the assembly to load from the requested package. When doing this it will first check the servicing index described above, if there is an entry for the given package it is loading then it will load the described assembly instead of finding the assembly as it normally would.

DNX Servicing

Index File

The other part of servicing is servicing the DNX itself. When a patch to a particular version of the DNX is installed then the index file will contain the following:

  • Type: will be dnx
  • Name: The name of the DNX, including bitness and CLR.
  • Version: The version of the DNX
  • Replacement DNX: The replacement DNX to load. The replacement path would be rooted at the location of the servicing index (see below).

For example:

dnx|clr-win-x64|1.0.0=/runtimes/dnx-clr-win-x64-1.0.0/

Mechanism

The main difference in the mechanisms between packages and the DNX is that the code that loads the DNX is native, and happens at a much earlier location. The code that does the DNX replacing depends on how you are running your app: Helios will do the lookup if it is being used The IIS native module will take care of servicing the DNX if you are using * dnx.exe will take care of servicing if you are self hosting by running dnx.exe directly.

Index file location

Windows

The index file needs to be installed in a location that is protected from anonymous modification. We default that location to:

c:\Program Files (x86)\DNX\Servicing\

You can change this by setting the DNX_SERVICING environment variable to a different path.