Peter Ritchie's Blog

Targeting .NET Standard for a class library means that the library will be compatible with applications designed for past versions of .NET. E.g., an application targeting .NET Framework 4.8 or .NET Core 2.1 will be able to load a class library targeting .NET Standard 2.0 because it can only rely on the same API surface that the application does.

There are a few reasons developers need to work in .NET Standard. A popular one is writing Roslyn analyzers, another is writing PowerShell modules (Cmdlets) in C#. .NET Standard is a formal specification of .NET APIs available across multiple .NET implementations. It's like a definition of a slice of APIs that are implemented across .NET versions. Designing for a slice of APIs allows you to design and deploy class libraries that will work across .NET implementations. The latest version of .NET Standard (2.1) was released in September 2020.

Paradoxically, .NET languages depend on base-class libraries for aspects of their implementation. For example, the C# language feature foreach depends on the types IEnumerable, IEnumerable<T>, IEnumerator, and IEnumerator<T>. Specifications like .NET Standard enable C# language features across .NET implementations by including those dependent types in their specification. But languages evolve and improve over time, as do base class libraries.

Since .NET Standard was last updated in 2020, some new language features that depend on new types in the base class library have been introduced. Some of these new language features aren't necessarily supported in .NET Standard, even though you can use the latest compiler version when building .NET Standard class libraries. For example, Ranges and Indices are a feature added to C# 8.0, released in September 2019. Ranges and Indices depend upon the Range and Index types. But to write a PowerShell library that supports Windows PowerShell and PowerShell 7, you have to target .NET Standard 2.0, whose API surface was specified around August 2017--roughly two years before Range and Index existed. This means Ranges and Indices aren't supported out of the box in C# code targeting .NET Standard 2.0. var lastWord = words[^1] or var firstFourWords = words[0..3] will cause errors (Predefined type 'System.Index' is not defined or imported, and Predefined type 'System.Range' is not defined or imported, respectively).

Fortunately, the compiler is flexible about where those predefined types are defined. Someone can't simply create a .NET Standard 2.0 library with Range and Index as public types, because they will clash with modern versions of .NET (e.g., in an XUnit test project). But the .NET Standard 2.0 library can create internal versions of those classes that the compiler is happy to resolve to. But having everyone who authors a .NET Standard 2.0 library write their own Range and Index classes (as well as any other class that modern C# syntax requires, like CallerArgumentExpressionAttribute, DoesNotReturnAttribute, etc.) is problematic, to say the least.

Content-only NuGet Packages

.NET and NuGet packages support content- or source-only packages. Source-only packages are NuGet packages that, instead of packaging binaries like DLLs, package source code. Source-only packages don't add any assembly dependencies that require deployment.

That's where Pri.ProductivityExtensions.Source comes in. Pri.ProductivityExtensions.Source is a source-only NuGet package that includes the source code for various types created after .NET Standard 2.x to support C# language features (and some helper extensions like ArgumentException.ThrowIfNull that depend on those features) that aren't available in .NET Standard.

"Pri.ProductivityExtensions.Source" is also the ID of the package and can be found on NuGet.org here. It can be added to a project via the .NET API: dotnet add package Pri.ProductivityExtensions.Source, or via Package Manager Console: Install-Package Pri.ProductivityExtensions.Source. It is open source, and the source code is available on GitHub. For an example using Pri.ProductivityExtensions.Source see Pri.Essentials.DotnetPsCmds. And if you install DotnetPsCmds, you can install Pri.ProductivityExtensions.Source in PowerShell: Add-DotnetPackages Pri.ProductivityExtensions.Source.

When you reference Pri.ProductivityExtensions.Source, it causes the content (source code) to be considered part of the target project. The source code remains in the .nuget cache and is not copied alongside the rest of your source code so no new source code needs to be committed to revision control.

The types included in Pri.ProductivityExtensions.Source are internal, so they won't clash if Pri.ProductivityExtensions.Source is referenced in a project targeting a modern .NET implementation. Although I don't recommend using Pri.ProductivityExtensions.Source in a .NET Standard class library that is targeting a modern .NET implementation because it will resolve to Pri.ProductivityExtensions.Source instead of the .NET implementation's.

If you've created a .NET Standard library and have wanted to use the latest version of the compiler but start receiving compiler errors like The type or namespace name 'CallerArgumentExpressionAttribute' does not exist in the namespace 'System.Runtime.CompilerServices' (are you missing an assembly reference?) or the other aforementioned errors, fear not, you simply need to reference Pri.ProductivityExtensions.Source!

Pri.ProductivityExtensions.Source enables the following modern C# compiler features:

Ranges and indices
[CallerArgumentExpression] 🔗
[DoesNotReturn] 🔗
[NotNullWhen] 🔗

Additionally, Pri.ProductivityExtensions.Source includes the following helper methods that otherwise depend on newer language-dependent types:

ArgumentException.ThrowIfNullOrWhiteSpace(string?, string?) 🔗
ArgumentNullException.ThrowIfNull(object?, string?) 🔗

Understanding C# Timeline Since Last .NET Standard

The last version of .NET Standard (2.1) was released in 2020. Since 2020, C# versions 10, 11, 12, 13, and 14 have been released. A lot has changed across 5 versions of C#, including the use of numerous APIs to enable various features. There isn't a complete list of base-class APIs that the C# compiler depends on.

If you find this useful
I'm a freelance software architect. If you find this post useful and think I can provide value to your team, please reach out to see how I can help. See About for information about the services I provide.

Things That Caught My Attention Last Week - January 19

Tue, 20 Jan 2026 00:00:00 GMT

Software Architecture

CQRS and Human Intent by Claudio Lassala

.NET

Stop Building SPAs for Every Screen: htmx + ASP.NET Core Razor Pages Workshop (Open) by Chris Woodruff

Generating SBOM for NuGet packages by Gérald Barré

How to Run Azure Service Bus Locally using .NET Aspire - YouTube by Milan Jovanović

.NET and .NET Framework January 2026 servicing releases updates by Rahul Bhandari (MSFT)

Copilot Memories by Jessie Houghton

How this website is built by Gérald Barré

How does Aspire expose resource connection info to the Azure Functions runtime? by Safia Abdalla

How JasperFx Supports our Customers by Jeremy D. Miller

Solving the Distributed Cache Invalidation Problem with Redis and HybridCache by Milan Jovanović

REST/APIs

A Shiny New OpenAPI Tools by Alexander Karan

Azure

Part 1: Building Your First Serverless HTTP API on Azure with Azure Functions & FastAPI by Richa Gaur

What's New in Azure Repos: Recent Updates by Dan Hellem

Software Development

Two regimes of Git by Mark Seemann

AI

Want better AI outputs? Try context engineering. by Christina Warren

Why LLMs Fail as Sensors (and What Brains Get Right) by Scott Galloway

Code Wave Build Log by Cassidy Williams

Intelligence without a witness by Mike Amundsen

Agents. It Is All APIs. Nothing Has Changed by Kin Lane

Things That Caught My Attention Last Week - January 12

Thu, 15 Jan 2026 00:00:00 GMT

Software Architecture

Solving Message Ordering from First Principles by Milan Jovanović

.NET

The Ultimate .NET Developer Roadmap 2026 - AI, Backend, Blazor & Full-Stack by Mukesh Murugan

Enterprise Patterns for ASP.NET Core: Front Controller and MVC Pattern by Chris Woodruff

Generate an Open Graph Profile Image with C# by Joseph Guadagno

EF Core MongoDB Queryable Encryption and Vector Search Explained by Rishit Bhatia

Recent updates to NetEscapades.EnumGenerators: new APIs and System.Memory support by Andrew Lock

Zero-copy BinaryData creation from MemoryStream in .NET by Gérald Barré

Reporting for duty: the story of IPipelineActivityReporter by Safia Abdalla

How to: NuGet local feeds by Karen Payne

Azure

Public Preview: Cosmos DB Mirroring in Microsoft Fabric with Private Endpoints by Mark Brown

Software Development

Hacktivist deletes white supremacist websites live onstage during hacker conference by Lorenzo Franceschi-Bicchierai

Coupling from a big-O perspective by Mark Seemann

MCP Is a Transport, Not an Architecture (English) by Scott Galloway

AI

How I Actually Use Claude Code in 2026, and Why It Still Needs a Parent by David Lee

A career chat with students in the age of AI by Cassidy Williams

Announcing DotnetPsCmds - PowerShell CmdLets for .NET

Mon, 12 Jan 2026 00:00:00 GMT

Have you ever wondered why there aren't PowerShell Cmdlets similar to dotnet CLI commands?

I've played around with some PowerShell scripts—including some scripts for scaffolding various .NET projects—and some C#-based CmdLets for various things. But I decided to take that experience to the next level by publishing a PowerShell module that provides dotnet CLI functionality while leveraging PowerShell idioms and features.

PowerShell has some interesting features that can make working in the command-line and building scripts a little nicer. One of those features is pipelining. Cmd and Bash have pipes, I know; but PowerShell takes it a step further by supporting object-oriented pipelining. A PowerShell CmdLet can have a .NET object as output (not just text) and can be propagated through the PowerShell command pipeline.

MVP

The initial (pre) release is very much an MVP--it provides what I consider minimal functionality to support scaffolding .NET solutions and projects. It essentially wraps dotnet CLI commands adding some convenience and opinions ("opinionation"?) to defaults and some features.

To get started with the cmdlets, you can import the module from the PowerShell Gallery:

Install-Module -Name Pri.Essentials.DotnetPsCmds

As this release builds on the .NET CLI, the .NET CLI still needs to be installed.

Creating a Solution

To create a solution in the current directory, with a solution name matching the name of the current directory (equivalent of dotnet new sln):

$s = New-DotnetSolution;

The output of this cmdlet is a object-oriented representation of the new solution.

Creating a Project

To create a project (a classlib project) in a new Domain directory with a project name of MyProduct.Domain (equivalent of dotnet new classlib -o Domain -n MyProduct.Domain).

$d = New-DotnetProject 'classlib' Domain MyProduct.Domain;

The output of this cmdlet is a object-oriented representation of the new project.

Adding Package References

With object instances of projects and solutions, we can now re-use those objects for other commands, like adding package references to a project:

$t = New-DotnetProject 'xunit' MyProduct/Tests MyProduct.Tests;
Add-DotnetPackages -PackageIds NSubstitute -Project $t;

Adding Project References

Similar to adding package references, project objects can be re-used when a project needs to reference another project:

$t = New-DotnetProject 'xunit' MyProduct/Tests MyProduct.Tests;
$d = New-DotnetProject 'classlib' Domain MyProduct.Domain;
Add-DotnetProjectReference -Project $d -TargetProject $t;

Leveraging Pipelining

DotNet PowerShell Commands support pipelining. For example, the output of New-DotnetSolution can be piped to New-DotnetProject to add the newly created project to the newly created solution:

New-DotnetSolution | New-DotnetProject 'classlib' Domain MyProduct.Domain;

You can store the solution object in a variable to enable adding multiple new projects to the solution:

$s = New-DotnetSolution;
$s | New-DotnetProject 'classlib' Domain MyProduct.Domain;
$s | New-DotnetProject 'xunit' Test MyProduct.Tests;

And pipelining works with adding package references:

$t = New-DotnetProject 'xunit' MyProduct/Tests MyProduct.Tests;
$t | Add-DotnetPackages -PackageIds NSubstitute;

As well as project references:

$d = New-DotnetProject 'classlib' Domain MyProduct.Domain;
New-DotnetProject 'xunit' Tests MyProduct.Tests `
    | Add-DotnetProjectReference -Project $d;

Or with project references and package references:

$d = New-DotnetProject 'classlib' Domain MyProduct.Domain;
$t = New-DotnetProject 'xunit' Tests MyProduct.Tests `
    | Add-DotnetPackages NSubstitute `
    | Add-DotnetProjectReference -Project $d;

Leveraging Objects

You can leverage properties of objects to avoid repeating yourself when creating solutions and projects with namespaces. For example, rather than having the "MyProduct" portion of the namespace/filename repeated, you can use the solution's Name property (assuming the current directory has the correct name as the "product name"):

$s = New-DotnetSolution;
$d = $s | New-DotnetProject 'classlib' "Domain" "$($s.Name).Domain";
$t = $s | New-DotnetProject 'xunit' "Tests" "$($s.Name).Tests" `
    | Add-DotnetPackages NSubstitute `
    | Add-DotnetProjectReference -Project $d;

Which, with equivalent to the following with dotnet:

dotnet new sln
dotnet new classlib -o Domain -n MyProduct.Domain
del Domain/Class1.cs
dotnet sln add Domain --in-root
dotnet new xunit -o Tests -n MyProduct.Tests
del Tests/UnitTest1.cs
dotnet add Tests package NSubstitute
dotnet add Tests reference Domain
dotnet sln add Tests --in-root

(For details on deleting Class1.cs and UnitTest1.cs, see below.)

Opinionated

I mentioned DotNet PowerShell Commands is opinionated in certain respects, here's where.

Solution Folders For Projects

I noticed recently that adding projects to a solution (dotnet sln add) automatically creates solution folders for projects whose name wasn't identical to the parent folder and doesn't add solution folders when the names are identical. (Using -o and -n with dotnet new <template> creates a project with a different name from the directory name.) Personally, I find it cumbersome to navigate the file system and especially repos like GitHub when I have project folders that match the project file name and fully-qualified project names (for the sake of default namespaces). e.g. repos/Pri.Essentials.DotnetPsCmds/src/Pri.Essentials.DotnetPsCmds/Pri.Essentials.DotnetPsCmds.csproj and tend toward shortened directory names for navigability and readability (repos/DotnetPsCmds/src/DotnetPsCmds/Pri.Essentials.DotnetPsCmds.csproj) because directory listings often just show a less than useful truncated list of folders that appear to have the same name (Maybe this is better solved with support for setting the default namespace when creating a project? But dotnet doesn't support that. 😉)

The implementation for this currently manifests in DotNet PowerShell Commands by using --in-root with dotnet sln add to avoid the creation of solution folders with new projects.

`Class1.cs`

Personally, the first thing I do when creating a class library project via dotnet or Visual Studio is to delete the Class1.cs file. DotNet PowerShell Commands automatically deletes this file when it creates a classlib project. I'm assuming users of DotNet PowerShell Commands are intermediate to advanced and feel the same way.

`UnitTest1.cs`

DotNet PowerShell Commands does the same thing with UnitTest1.cs in xunit/xunit3 projects as it does with Class1.cs in classlib projects.

Extra Features, So Far

Over and above what dotnet provides, DotNet PowerShell Commands also allows creating a custom solution folder when adding a project to a solution via Add-DotnetProject (not to be confused with New-DotnetProject). This is partially to circumvent the opinionated view that hardly anyone would want a solution folder per project by default. But this provides extra value in that if you use the same folder name with the addition multiple projects, all the projects will be grouped in the same solution folder.

$d = New-DotnetProject 'classlib' Domain MyProduct.Domain;
$s = New-DotnetSolution;
$s | Add-DotnetProject -Project $d -SolutionFolder MyFolder;

More details

For more details, please see the open-source project on GitHub. In there you'll find a more thorough README that goes into a bit more detail on CmdLets and examples. You can also create issues or discussions with questions/suggestions in addition to contributing.

I'd like to pull together a simple roadmap for what I'm thinking for this in the near future. Some things I'm thinking so far are:

supporting slnx files (by default?)
Templated solutions: creating all the parts of common solution templates in a single command.
supporting solution-level features like Directory.Build.props, global.json
GitHub repo features like workflows, dependabot, etc.
Support modifying project-level properties via commands (like GenerateDocumentationFile, PublishRepositoryUrl, etc.)

If you find this useful
I'm a freelance software architect. If you find this post useful and think I can provide value to your team, please reach out to see how I can help. See About for information about the services I provide.