Switch branches/tags
Clone or download
MS-TimothyMothra Tilee/update public api (#947)
* add script. merge text files
Latest commit d203133 Oct 9, 2018
Failed to load latest commit information.
.github merge develop to master for 2.5.0-beta2 (#668) Dec 4, 2017
.vscode merge develop to master for 2.5.0-beta2 (#668) Dec 4, 2017
.vsts Linux build to emit trx files from test runs. Jul 30, 2018
PublicAPI Tilee/update public api (#947) Oct 9, 2018
SDL sdl script revisions (#691) Jan 12, 2018
Schema Removed measurements field and its ConcurrentDictionary instantiation… Oct 3, 2018
Test tc null checks tests Oct 8, 2018
docs fixed some typos Aug 3, 2018
src Avoid unnecessary dictionary instantiation. continuing from previous PR Oct 9, 2018
.PreReleaseVersion fixed versions Mar 14, 2017
.gitattributes Adding gitattributes Feb 5, 2016
.gitignore Ignore vswhere folder Apr 9, 2018
35MSSharedLib1024.snk add public key file Sep 28, 2015
AddXmlLanguage.targets Merge pull request #870 from Microsoft/dmitmatv_xmldoc Jul 31, 2018
ApplicationInsightsSDKRules.ruleset enable warnings as errors (#912) Sep 20, 2018 Bump version 2.8.0 (#943) Oct 9, 2018
CodeCov.ps1 fixed missing tick in the line end Aug 17, 2017
Common.props enable warnings as errors (#912) Sep 20, 2018
Common.targets Added targets to update the XML docs post build with a language attri… Sep 6, 2016
Directory.Build.props merge develop to master for 2.5.0-beta2 (#668) Dec 4, 2017
EnlistmentRoot.marker Restructuring the Core SDK and CoreSDK Tests to fit the GitHub structure Jul 13, 2015
FinalizePublicApi.ps1 Tilee/update public api (#947) Oct 9, 2018
GenerateReleaseMetadata.ps1 release metadata Apr 11, 2018
GlobalStaticVersion.props Bump version 2.8.0 (#943) Oct 9, 2018
LICENSE Create License Sep 14, 2015
Microsoft-Security-Recommended.ruleset Added rules and enabled code analysis on build. Aug 12, 2016
Microsoft.ApplicationInsights.sln standardize nupkg attributes (#924) Sep 26, 2018
NuGet.config merge develop to master for 2.5.0-beta2 (#668) Dec 4, 2017
NuGet.exe add script to audit nupkg during build (#938) Oct 8, 2018
NugetAudit.ps1 add script to audit nupkg during build (#938) Oct 8, 2018
Nupkg.props standardize nupkg attributes (#924) Sep 26, 2018
PushNugetPackages.cmd fix uploading to myget Oct 23, 2015 Update (#724) Mar 7, 2018
Signing.targets few clean up tasks Aug 3, 2017
Test.props no more core Aug 11, 2017
VSOPushNugetPackages.cmd Whitespace corrections Jan 22, 2016
buildDebug.cmd Move to a master Core project Mar 12, 2017
buildRelease.cmd Shuffle projects around Mar 12, 2017
clean.cmd Added script to clean. Jun 16, 2017
dirs.proj merge develop to master for 2.5.0-beta2 (#668) Dec 4, 2017
disablestrongnamevalidation.ps1 Added non x64 version of sn.exe Jun 21, 2017
enablestrongnamevalidation.ps1 Added non x64 version of sn.exe Jun 21, 2017
findMsBuild.cmd revert echo off removal Mar 14, 2017

Build Status

NuGet packages

Application Insights for .NET

This repository has code for the base .NET SDK for Application Insights. Application Insights is a service that allows developers ensure their application are available, performing, and succeeding. This SDK provides the base ability to send all Application Insights types from any .NET project.

Getting Started

If developing for a .Net project that is supported by one of our platform specific packages, Web or Windows Apps, we strongly recommend to use one of those packages instead of this base library. If your project does not fall into one of those platforms you can use this library for any .Net code. This library should have no dependencies outside of the .Net framework. If you are building a Desktop or any other .Net project type this library will enable you to utilize Application Insights. More on SDK layering and extensibility later.

Get an Instrumentation Key

To use the Application Insights SDK you will need to provide it with an Instrumentation Key which can be obtained from the portal. This Instrumentation Key will identify all the data flowing from your application instances as belonging to your account and specific application.

Add the SDK library

We recommend consuming the library as a NuGet package. Make sure to look for the Microsoft.ApplicationInsights package. Use the NuGet package manager to add a reference to your application code.

Initialize a TelemetryClient

The TelemetryClient object is the primary root object for the library. Almost all functionality around telemetry sending is located on this object. You must initialize an instance of this object and populate it with your Instrumentation Key to identify your data.

using Microsoft.ApplicationInsights;

var tc = new TelemetryClient();
tc.InstrumentationKey = "INSERT YOUR KEY";

Use the TelemetryClient to send telemetry

This "base" library does not provide any automatic telemetry collection or any automatic meta-data properties. You can populate common context on the TelemetryClient.context property which will be automatically attached to each telemetry item sent. You can also attach additional property data to each telemetry item sent. The TelemetryClient also exposes a number of Track...() methods that can be used to send all telemetry types understood by the Application Insights service. Some example use cases are shown below.

tc.Context.User.Id = Environment.GetUserName(); // This is probably a bad idea from a PII perspective.
tc.Context.Device.OperatingSystem = Environment.OSVersion.ToString();


tc.TrackEvent("PurchaseOrderSubmitted", new Dictionary<string, string>() { {"CouponCode", "JULY2015" } }, new Dictionary<string, double>() { {"OrderTotal", 68.99 }, {"ItemsOrdered", 5} });
catch(Exception e)

Ensure you don't lose telemetry

This library makes use of the InMemoryChannel to send telemetry data. This is a very lightweight channel implementation. It stores all telemetry to an in-memory queue and batches and sends telemetry. As a result, if the process is terminated suddenly, you could lose telemetry that is stored in the queue but not yet sent. It is recommended to track the closing of your process and call the TelemetryClient.Flush() method to ensure no telemetry is lost.

Full API Overview

Read about how to use the API and see the results in the portal.

SDK layering

This repository builds two packages - Microsoft.ApplicationInsights and Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel. These packages define public API, reliable channel to Application Insights back-end and data reduction code like metrics pre-aggregation and sampling. Data collection, enrichment and filtering implemented as separate NuGet packages. These separate NuGet packages are using extensibility points explained below.

Application Insights SDK defines the following layers: data collection, public API, telemetry initialization and enrichment, data reduction pipeline and finally - telemetry sink.

Data collection layer represented by various telemetry modules - officially supported and community created. Each module converts events exposed by platform like ASP.NET into Application Insights data model. For example, dependency collection telemetry module subscribes on begin and end events of System.Net.HttpClient and calls TrackDependency API. This module knows how to collect dependency name, target, and other properties from those begin and end events.

Telemetry initialization and enrichment allows to modify telemetry items. There are two typical scenarios for the enrichment. First - stamp every telemetry item with the platform or application specific context. Examples may be application version, user id or flighting name for A/B testing. Second scenario is re-writing properties of the telemetry data collected automatically. For instance, dependency collection telemetry module collects the http dependency name as a url path and telemetry initializer may change this behavior for well-known urls.

Data reduction pipeline is a linked list of telemetry processors. Each telemetry processor may decide to pre-aggregate and filter telemetry item or pass it to the next processor. This way only interesting telemetry reaches to the end of the pipeline and being send to the telemetry sinks.

Each Telemetry sink is responsible to upload telemetry to the specific back-end. Default telemetry sink sends data to the Application Insights. Sinks may also differ in guarantees they provide while uploading to the same back end. One may implement reliable delivery with re-tries and persistance when another may implement send and forget type of upload. Every telemetry sink may have it's own pipeline for additional data filtering and pre-aggregation.

Set of telemetry initializers called synchronously for every telemetry item. So extra properties can be added to the item. By this time telemetry item is fully initialized. Build pipeline to aggregate or filter telemetry. Set of telemetry sinks to upload data in various back-ends. Every sink has it's own pipeline for extra filtering and data aggregation.

Here is the diagram of Application Insights SDK layering and extensibility points:

Layer Extensibility
collection Pick one of existing modules
or manually instrument code
public-api Track custom operations
and other telemetry
initialization Pick telemetry initializers
or create your own
pipeline Configure sampling,
create filtering telemetry processor
or strip out confidential data
sink For the default sink:
Use built-in channel or
use server channel for reliable delivery.
Configure EventFlow to upload telemetry
to ElasticSearch
Azure EventHub and
and more

Packages like Microsoft.ApplicationInsights.Web or Microsoft.ApplicationInisghts.AspNetCore install a set of telemetry modules, telemetry initializers and default sinks that works for the most scenarios. However SDK is designed to be flexible so you can pick and choose components on every layer for the best telemetry data for your application.


  • master contains the latest published release located on NuGet.
  • develop contains the code for the next release.


We strongly welcome and encourage contributions to this project. Please read the general contributor's guide located in the ApplicationInsights-Home repository and the contributing guide for this SDK. If making a large change we request that you open an issue first. We follow the Git Flow approach to branching.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact with any additional questions or comments.