DotNetLibraryPackageTemplates 1.3.0

.NET CLI

dotnet new install DotNetLibraryPackageTemplates::1.3.0

This package contains a .NET Template Package you can call from the shell/command line.

About

What's this?

A bunch of dotnet new templates to quickly get you started building high-quality binary or source-only open-source and non-open-source libraries including everything you need to publish it on NuGet or make it available as open-source.

It includes:

Multi-targeting to cover as many .NET frameworks as possible
Separate templates for internal (or "inner sourced") as well as open-source libraries
Support for both GitHub and Azure DevOps Repositories/Pipelines
Can create projects for binary or source-only packages
Code coverage using Coverlet and Coveralls.io
Static code analysis using Roslyn analyzers StyleCopAnalyzers, Roslynator, CSharpGuidelinesAnalyzer and Meziantou.
Auto-formatting using (a slightly opinionated) .editorconfig and settings honored by JetBrains Rider and ReSharper
A Nuke C# build script that you can run locally as well as in your CI/CD pipeline
A GitHub Actions workflow that builds, tests, packages and publishes your library
GitHub issue templates to streamline bug reporting and feature requests
An extensive read-me
Automatic versioning using GitVersion and tagging
Contribution guidelines
Customized release notes templates for GitHub connected to pull requests labels.
A test project using xUnit and Fluent Assertions 7
Validation of the public API of the library against snapshots using Verify
NuGet auditing using .NET built-in auditing capabilities
NuGet package and licensing scanning through PackageGuard

What's so special about that?

I like to build my software systems in a nicely broken down set of libraries that are easy to maintain, test and deploy based on the Principles Of Successful Package Management. However, every time I or the teams I work with need to start a new library or reusable component, we have to piece together so much from other projects that I felt this would fill the gap.

This is the result of years of experience in building in-house and open-source libraries that are used by thousands of developers around the world. I hope it's a great starting point for building your own libraries.

Tip You can also use this as a starting point for a GitHub Template Repository, fork and adapt the repository for your own company, or use it as an organization template in Azure DevOps.

Who created this?

My name is Dennis Doomen and I'm a Microsoft MVP and Principal Consultant at Aviva Solutions with 29 years of experience under my belt. As a coding architect, I specialize in designing full-stack enterprise solutions based on .NET as well as providing coaching on all aspects of designing, building, deploying and maintaining software systems. I'm the author of several open-source projects such as Fluent Assertions, Reflectify, Liquid Projections, and I've been maintaining coding guidelines for C# since 2001.

Contact me through Email, Bluesky, Twitter/X or Mastadon

How do I use it?

Generating the library skeleton

Create a new directory for your library initialized with Git
Run the following command to start building an internal library for GitHub

dotnet new nooss-binary-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary

Or, if you prefer to build a NuGet package that only adds source files to a project (and avoids binary dependencies)

dotnet new nooss-source-only-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary

Or, if you want to build an open-source packages, use either of the following

dotnet new oss-binary-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary

dotnet new oss-source-only-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary

If you are still using Azure DevOps, we got you covered, but you need the organization and project names as well. Again, choose between a binary package or a source-only package.

dotnet new azdo-binary-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary --organization MyDevOpsOrganization --project MyDevOpsProject

dotnet new azdo-source-only-nuget-class-library-sln --name TheNameOfYourAwesomeLibrary --organization MyDevOpsOrganization --project MyDevOpsProject
Make the necessary changes to the generated code (see next section)
Commit the changes to your repository into a new commit. Without it, the build script will crash on generating the version number.
Run build.ps1 to build the code, run the tests, and package the library into a NuGet package in the Artifacts directory.

What to do after that

The template makes a lot of assumptions, so after generating the project, there's a couple of things you can tweak.

Update the Readme.md and PackageReadme.md with information about your library
Review the guidelines in CONTRIBUTING.md to see if it aligns with how you want to handle contributions
Review the issue templates under .github/issue_template
Adjust the .NET frameworks this library should target
Adjust the root namespace and assembly names
Set-up labels in GitHub matching those in the release.yml so you can label pull requests accordingly
Alter the coverage service that is being used.
Determine if you want to use API verification against snapshots
Study the Nuke build.cs file or invoking it through build.ps1 -plan to see how it works
See if all dependencies are up-to-date
Configure NuGet auditing (see next paragraph)
Check out the allowed open-source licenses and packages in the PackageGuard.config.json
Adjust the funding.yml to allow people to sponsor your project

Additional things to be aware of

About NuGet auditing

By default, a dotnet restore will also check the NuGet packages for any vulnerabilities. If you run into those, there are a couple of options you can take.

Update the dependencies to a version that resolve the vulnerability
Update the WarningsNotAsErrors element in the Directory.Build.Props file to include the relevant NU190x error codes as listed here.
Disable auditing entirely by setting the NuGetAudit element to false in that same Directory.Build.Props file.

About API verification

The ApiVerificationTests will generate a .txt file containing a representation (per target framework) of the public API of your library. It's a nice technique to prevent accidentally introducing breaking changes. So, whenever the structure of your API changes compared to the snapshot stored in the ApprovedApi folder, the test will fail. You can then use AcceptApiChanges.ps1 to update the snapshots and make the test succeed again.

Versioning

This library uses Semantic Versioning to give meaning to the version numbers. For the versions available, see the tags on this repository.

Credits

This library wouldn't have been possible without the following tools, packages and companies:

ASP.NET Core Template - Created by Nikolay Kostov and the inspiration for this repo.
Scriban - A fast, powerful, safe and lightweight scripting language and engine by Alexandre Mutel
Nuke - Smart automation for DevOps teams and CI/CD pipelines by Matthias Koch
Rider - The world's most loved .NET and game dev IDE by JetBrains
xUnit - Community-focused unit testing tool for .NET by Brad Wilson
Coverlet - Cross platform code coverage for .NET by Toni Solarin-Sodara
Polysharp - Generated, source-only polyfills for C# language features by Sergio Pedri
GitVersion - From git log to SemVer in no time
ReportGenerator - Converts coverage reports by Daniel Palme
StyleCopyAnalyzer - StyleCop rules for .NET
Roslynator - A set of code analysis tools for C# by Josef Pihrt
CSharpCodingGuidelines - Roslyn analyzers by Bart Koelman to go with the C# Coding Guidelines
Meziantou - Another set of awesome Roslyn analyzers by Gérald Barré
Verify - Snapshot testing by Simon Cropp

Support the project

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version	Downloads	Last Updated
1.3.0	43	6/29/2025
1.2.0	145	6/16/2025
1.1.0	475	3/24/2025
1.0.0	135	1/19/2025