Libraries & Extensions

Creating Class Libraries

Class libraries encapsulate reusable logic that can be shared across multiple applications. Create one with:

dotnet new classlib -n MyLibrary
cd MyLibrary
dotnet build

This generates a .csproj targeting net8.0 (or your current SDK version) with <OutputType>Library</OutputType>.

.NET Standard vs Target Framework Moniker (TFM)

.NET Standard is a formal specification of APIs that all .NET implementations must implement. It allows libraries to work across .NET Framework, .NET Core, and Xamarin.

TFM	Target
`netstandard2.0`	Broadest compatibility (all .NET implementations)
`netstandard2.1`	Latest standard (not supported by .NET Framework 4.x)
`net8.0`	.NET 8 (modern, cross-platform)
`net6.0`	.NET 6 (LTS, widely deployed)

For new libraries targeting only modern .NET, use a specific TFM like net8.0. If you need compatibility with .NET Framework or Xamarin, target netstandard2.0.

NuGet Package Creation

A NuGet package bundles a compiled library (.dll) with metadata, dependencies, and optional content files.

Using `.nuspec`

<?xml version="1.0"?>
<package>
    <metadata>
        <id>MyLibrary</id>
        <version>1.0.0</version>
        <authors>YourName</authors>
        <description>A useful library</description>
    </metadata>
</package>

Pack and Push

dotnet pack -c Release
dotnet nuget push bin\Release\MyLibrary.1.0.0.nupkg --api-key YOUR_KEY --source https://api.nuget.org/v3/index.json

You can also publish to a local feed, Azure Artifacts, or GitHub Packages by changing the --source URL.

UWP Apps and Windows Runtime (WinRT) Components

Universal Windows Platform (UWP) apps can consume .NET Standard libraries. WinRT components (created in C++/CX or C#) expose APIs that can be consumed by any UWP language (C#, JavaScript, C++).

Extension SDKs

Extension SDKs provide platform-specific APIs for Windows development (e.g., Windows Mobile SDK, Xbox Live SDK). They are referenced in the project file and resolved by the build system based on the target platform.

Portable Class Libraries (PCL)

PCLs were the predecessor to .NET Standard. They allowed targeting specific combinations of platforms (e.g., iOS + Android + Windows Phone) by defining a "profile" of available APIs.

PCLs are deprecated in favor of .NET Standard. If you maintain a PCL, migrate it to netstandard2.0 to gain access to more APIs and broader compatibility.

Sharing Libraries Across Projects

You can reference a library project directly in a solution or via a NuGet package. Direct project references are simpler during development:

dotnet add ConsoleApp.csproj reference ..\MyLibrary\MyLibrary.csproj

Xamarin.Forms

Xamarin.Forms allows sharing UI code across iOS, Android, and Windows using a single .NET class library. Shared logic lives in a .NET Standard library, while platform-specific renderers and services live in individual platform projects.

PCL Troubleshooting

Common issues include missing API members due to profile limitations, mismatched platform versions, and assembly binding failures. Use the PlatformNotSupportedException guard to handle missing APIs gracefully.

Exercise: Create a class library with a utility method (e.g., a string extension method), package it as a NuGet package using dotnet pack, and consume it from a console application. Publish the package to a local feed.