Developing Libraries with Cross Platform Tools

This article covers how to write libraries for .NET using cross-platform CLI tools. The CLI provides an efficient and low-level experience that works across any supported OS. You can still build libraries with Visual Studio, and if that is your preferred experience refer to the Visual Studio guide.


You need the .NET Core SDK and CLI installed on your machine.

For the sections of this document dealing with .NET Framework versions, you need the .NET Framework installed on a Windows machine.

Additionally, if you wish to support older .NET Framework targets, you need to install targeting/developer packs for older framework versions from the .NET target platforms page. Refer to this table:

.NET Framework Version What to download
4.6.1 .NET Framework 4.6.1 Targeting Pack
4.6 .NET Framework 4.6 Targeting Pack
4.5.2 .NET Framework 4.5.2 Developer Pack
4.5.1 .NET Framework 4.5.1 Developer Pack
4.5 Windows Software Development Kit for Windows 8
4.0 Windows SDK for Windows 7 and .NET Framework 4
2.0, 3.0, and 3.5 .NET Framework 3.5 SP1 Runtime (or Windows 8+ version)

How to target the .NET Standard

If you're not quite familiar with the .NET Standard, refer to the .NET Standard Library to learn more.

In that article, there is a table which maps .NET Standard versions to various implementations:

.NET Standard 1.0 1.1 1.2 1.3 1.4 1.5 1.6 2.0
.NET Core 1.0 1.0 1.0 1.0 1.0 1.0 1.0 2.0
.NET Framework (with tooling 1.0) 4.5 4.5 4.5.1 4.6 4.6.1 4.6.2
.NET Framework (with tooling 2.0) 4.5 4.5 4.5.1 4.6 4.6.1 4.6.1 4.6.1 4.6.1
Mono 4.6 4.6 4.6 4.6 4.6 4.6 4.6 vNext
Xamarin.iOS 10.0 10.0 10.0 10.0 10.0 10.0 10.0 vNext
Xamarin.Android 7.0 7.0 7.0 7.0 7.0 7.0 7.0 vNext
Universal Windows Platform 10.0 10.0 10.0 10.0 10.0 vNext vNext vNext
Windows 8.0 8.0 8.1
Windows Phone 8.1 8.1 8.1
Windows Phone Silverlight 8.0
  • The columns represent .NET Standard versions. Each header cell is a link to a document that shows which APIs got added in that version of .NET Standard.
  • The rows represent the different .NET platforms.
  • The version number in each cell indicates the minimum version of the platform you'll need to implement that .NET Standard version.

Here's what this table means for the purposes of creating a library:

The version of the .NET Platform Standard you pick will be a tradeoff between access to the newest APIs and ability to target more .NET platforms and Framework versions. You control the range of targetable platforms and versions by picking a version of netstandardX.X (Where X.X is a version number) and adding it to your project file (.csproj or .fsproj).

You have three primary options when targeting the .NET Standard, depending on your needs.

  1. You can use the default version of the .NET Standard supplied by templates - netstandard1.4 - which gives you access to most APIs on .NET Standard while still being compatible with UWP, .NET Framework 4.6.1, and the forthcoming .NET Standard 2.0.

    <Project Sdk="Microsoft.NET.Sdk">
  2. You can use a lower or higher version of the .NET Standard by modifying the value in the TargetFramework node of your project file.

    .NET Standard versions are backward compatible. That means that netstandard1.0 libraries run on netstandard1.1 platforms and higher. However, there is no forward compatibility - lower .NET Standard platforms cannot reference higher ones. This means that netstandard1.0 libraries cannot reference libraries targeting netstandard1.1 or higher. Select the Standard version that has the right mix of APIs and platform support for your needs. We recommend netstandard1.4 for now.

  3. If you want to target the .NET Framework versions 4.0 or below, or you wish to use an API available in the .NET Framework but not in the .NET Standard (for example, System.Drawing), read the following sections and learn how to multitarget.

How to target the .NET Framework


These instructions assume you have the .NET Framework installed on your machine. Refer to the Prerequisites to get dependencies installed.

Keep in mind that some of the .NET Framework versions used here are no longer in support. Refer to the .NET Framework Support Lifecycle Policy FAQ about unsupported versions.

If you want to reach the maximum number of developers and projects, use the .NET Framework 4.0 as your baseline target. To target the .NET Framework, you will need to begin by using the correct Target Framework Moniker (TFM) that corresponds to the .NET Framework version you wish to support.

.NET Framework 2.0   --> net20
.NET Framework 3.0   --> net30
.NET Framework 3.5   --> net35
.NET Framework 4.0   --> net40
.NET Framework 4.5   --> net45
.NET Framework 4.5.1 --> net451
.NET Framework 4.5.2 --> net452
.NET Framework 4.6   --> net46
.NET Framework 4.6.1 --> net461
.NET Framework 4.6.2 --> net462
.NET Framework 4.7 --> net47

You then insert this TFM into the TargetFramework section of your project file. For example, here's how you would write a library which targets the .NET Framework 4.0:

<Project Sdk="Microsoft.NET.Sdk">

And that's it! Although this compiled only for the .NET Framework 4, you can use the library on newer versions of the .NET Framework.

How to Multitarget


The following instructions assume you have the .NET Framework installed on your machine. Refer to the Prerequisites section to learn which dependencies you need to install and where to download them from.

You may need to target older versions of the .NET Framework when your project supports both the .NET Framework and .NET Core. In this scenario, if you want to use newer APIs and language constructs for the newer targets, use #if directives in your code. You also might need to add different packages and dependencies for each platform you're targeting to include the different APIs needed for each case.

For example, let's say you have a library that performs networking operations over HTTP. For .NET Standard and the .NET Framework versions 4.5 or higher, you can use the HttpClient class from the System.Net.Http namespace. However, earlier versions of the .NET Framework don't have the HttpClient class, so you could use the WebClient class from the System.Net namespace for those instead.

Your project file could look like this:

<Project Sdk="Microsoft.NET.Sdk">

  <!-- Need to conditionally bring in references for the .NET Framework 4.0 target -->
  <ItemGroup Condition="'$(TargetFramework)' == 'net40'">
    <Reference Include="System.Net" />

  <!-- Need to conditionally bring in references for the .NET Framework 4.5 target -->
  <ItemGroup Condition="'$(TargetFramework)' == 'net45'">
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Threading.Tasks" />

You'll notice three major changes here:

  1. The TargetFramework node has been replaced by TargetFrameworks, and three TFMs are expressed inside.
  2. There is an <ItemGroup> node for the net40 target pulling in one .NET Framework references.
  3. There is an <ItemGroup> node for the net45 target pulling in two .NET Framework references.

The build system is aware of the following preprocessor symbols used in #if directives:

.NET Framework 2.0   --> NET20
.NET Framework 3.5   --> NET35
.NET Framework 4.0   --> NET40
.NET Framework 4.5   --> NET45
.NET Framework 4.5.1 --> NET451
.NET Framework 4.5.2 --> NET452
.NET Framework 4.6   --> NET46
.NET Framework 4.6.1 --> NET461
.NET Framework 4.6.2 --> NET462
.NET Standard 1.0    --> NETSTANDARD1_0
.NET Standard 1.1    --> NETSTANDARD1_1
.NET Standard 1.2    --> NETSTANDARD1_2
.NET Standard 1.3    --> NETSTANDARD1_3
.NET Standard 1.4    --> NETSTANDARD1_4
.NET Standard 1.5    --> NETSTANDARD1_5
.NET Standard 1.6    --> NETSTANDARD1_6

Here is an example making use of conditional compilation per-target:

using System;
using System.Text.RegularExpressions;
#if NET40
// This only compiles for the .NET Framework 4 targets
using System.Net;
 // This compiles for all other targets
using System.Net.Http;
using System.Threading.Tasks;

namespace MultitargetLib
    public class Library
#if NET40
         private readonly WebClient _client = new WebClient();
         private readonly object _locker = new object();
        private readonly HttpClient _client = new HttpClient();

#if NET40
        // .NET Framework 4.0 does not have async/await
        public string GetDotNetCount()
            string url = "";

            var uri = new Uri(url);

            string result = "";

            // Lock here to provide thread-safety.
                result = _client.DownloadString(uri);

            int dotNetCount = Regex.Matches(result, ".NET").Count;

            return $"Dotnet Foundation mentions .NET {dotNetCount} times!";
         // .NET 4.5+ can use async/await!
         public async Task<string> GetDotNetCountAsync()
             string url = "";

             // HttpClient is thread-safe, so no need to explicitly lock here
             var result = await _client.GetStringAsync(url);

             int dotNetCount = Regex.Matches(result, ".NET").Count;

             return $" mentions .NET {dotNetCount} times in its HTML!";

If you build this project with dotnet build, you'll notice three directories under the bin/ folder:


Each of these contain the .dll files for each target.

How to test libraries on .NET Core

It's important to be able to test across platforms. You can use either xUnit or MSTest out of the box. Both either are perfectly suitable for unit testing your library on .NET Core. How you set up your solution with test projects will depend on the structure of your solution. The following example assumes that test and source directories live in the same top-level directory.

[!INFO] This uses some .NET CLI commands. See dotnet new and dotnet sln for more information.

  1. Set up your solution. You can do so with the following commands:
mkdir SolutionWithSrcAndTest
cd SolutionWithSrcAndTest
dotnet new sln
dotnet new classlib -o MyProject
dotnet new xunit -o MyProject.Test
dotnet sln add MyProject/MyProject.csproj
dotnet sln add MyProject.Test/MyProject.Test.csproj

This will create projects and link them together in a solution. Your directory for SolutionWithSrcAndTest should look like this:

  1. Navigate to the test project's directory and add a reference to MyProject.Test from MyProject.
cd MyProject.Test
dotnet add reference ../MyProject/MyProject.csproj
  1. Restore packages and build projects:
dotnet restore
dotnet build
  1. Verify that xUnit runs by executing the dotnet test command. If you chose to use MSTest, then the MSTest console runner should run instead.

And that's it! You can now test your library across all platforms using command line tools. To continue testing now that you have everything set up, testing your library is very simple:

  1. Make changes to your library.
  2. Run tests from the command line, in your test directory, with dotnet test command.

Your code will be automatically rebuilt when you invoke dotnet test command.

How to use multiple projects

A common need for larger libraries is to place functionality in different projects.

Imagine you wished to build a library which could be consumed in idiomatic C# and F#. That would mean that consumers of your library consume them in ways which are natural to C# or F#. For example, in C# you might consume the library like this:

using AwesomeLibrary.CSharp;

public Task DoThings(Data data)
    var convertResult = await AwesomeLibrary.ConvertAsync(data);
    var result = AwesomeLibrary.Process(convertResult);
    // do something with result

In F#, it might look like this:

open AwesomeLibrary.FSharp


let doWork data = async {
    let! result = AwesomeLibrary.AsyncConvert data // Uses an F# async function rather than C# async method
    // do something with result

Consumption scenarios like this mean that the APIs being accessed have to have a different structure for C# and F#. A common approach to accomplishing this is to factor all of the logic of a library into a core project, with C# and F# projects defining the API layers that call into that core project. The rest of the section will use the following names:

  • AwesomeLibrary.Core - A core project which contains all logic for the library
  • AwesomeLibrary.CSharp - A project with public APIs intended for consumption in C#
  • AwesomeLibrary.FSharp - A project with public APIs intended for consumption in F#

You can run the following commands in your terminal to produce the same structure as this guide:

dotnet new sln
mkdir AwesomeLibrary.Core && cd AwesomeLibrary.Core && dotnet new classlib
cd ..
mkdir AwesomeLibrary.CSharp && cd AwesomeLibrary.CSharp && dotnet new classlib
cd ..
mkdir AwesomeLibrary.FSharp && cd AwesomeLibrary.FSharp && dotnet new classlib -lang F#
cd ..
dotnet sln add AwesomeLibrary.Core/AwesomeLibrary.Core/csproj
dotnet sln add AwesomeLibrary.CSharp/AwesomeLibrary.CSharp/csproj
dotnet sln add AwesomeLibrary.FSharp/AwesomeLibrary.FSharp/csproj

This will add the three projects above and a solution file which links them together. Creating the solution file and linking projects will allow you to restore and build projects from a top-level.

Project-to-project referencing

The best way to reference a project is to use the .NET CLI to add a project reference. From the AwesomeLibrary.CSharp and AwesomeLibrary.FSharp project directories, you can run the following command:

$ dotnet add reference ../AwesomeLibrary.Core.csproj

The project files for both AwesomeLibrary.CSharp and AwesomeLibrary.FSharp will now reference AwesomeLibrary.Core as a ProjectReference target. You can verify this by inspecting the project files and seeing the following in them:

    <ProjectReference Include="..\AwesomeLibrary.Core\AwesomeLibrary.Core.csproj" />

You can add this section to each project file manually if you prefer not to use the .NET CLI.

Structuring a Solution

Another important aspect of multi-project solutions is establishing a good overall project structure. You can organize code however you like, and as long as you link each project to your solution file with dotnet sln add, you will be able to run dotnet restore and dotnet build at the solution level.