.NET Dependency Guidelines

Motivation

Why is it important to keep care of .NET dependencies?

• Lower maintenance effort for code which must be maintained for more than 3 years.
• Simplify migration to the “next” supported .NET runtime.
• Increase the re-use potential.
• Reduce the risk of a “lock in” to legacy runtimes or outdated coding approaches.

Dependency types

This chapter contains general guidelines regarding dependencies.

Target Framework

The target framework specifies the supported runtimes and the API set which can be used by the library or the application.

• Consider targeting .NET Standard 2.0 or .NET Core if appropriate.
• Avoid targeting the .NET Framework because this product is set to maintenance mode and will not be developed any further.
• Do not target non-LTS versions of .NET Core. These versions are maintained by a very short time. After the end of maintenance lifecycle, no security updates are provided anymore.
• Do not target the PCL (Portable Class Library) as they are deprecated.

See also: Target frameworks in SDK-style projects

Assembly references

• Consider including assemblies via the NuGet package management solution.

Application development

Specific guidelines for developing .NET applications are listed here.

• Consider targeting the latest .NET Core LTS version. .NET Core is future proof as the next .NET versions will base on it. At the time of writing this page the latest LTS version is .NET Core 3.1.

Library authors

The following guidelines are relevant for writing re-usable libraries.

• Consider targeting .NET Standard 2.0.
  • Pro: Supported by all important .NET runtimes: .NET Core, .NET Framework and Mono (Xamarin).
  • Con: Does not provide the latest API set.
• Consider deploying libraries as NuGet packages. Consider using NuGet.org for open-source and publicly available libraries.
• Avoid referencing 3rd party libraries if this is an option. Keep the dependencies at a minimum.
• Do not reference libraries which enforce the application to use specific frameworks. Examples:
  • Logging: Avoid NLog, Serilog or any other 3rd party logging framework. Instead consider to use the built-in TraceSource. See Logging with .NET Standard 2.0.
  • Reactive Extensions (RX): Avoid using it in public API.
• Do not ignore the NuGet warning NU1701. The warning let users know that the dependencies may not be 100% compatible. See NuGet Warning NU1701

Further readings

• Open-source library guidance