Building libraries and components
A common requirement when you start to build more complex applications is to split a solution into multiple projects, with the goal of increasing reusability and having a clearer separation across various components.
When you're building a Windows application that uses the Windows App SDK, you have two options to choose from:
- A WinUI class library
- A .NET class library
Let's discuss each option in detail.
Using a WinUI class library
A WinUI class library is the best choice when you're building a library that contains code specific to the Windows App SDK and WinUI. It's a great fit when you want to store the following:
- Custom controls or user controls for WinUI
- Classes that use specific Windows 10 APIs
This type of class library is a great fit when you want to share code across multiple WinUI applications. To create a WinUI class library, you can use the template in Visual Studio called Class Library (WinUI 3 in Desktop).
Using a .NET class library
A .NET class library is the best choice when you're building a library that doesn't include any code that is specific to the Windows App SDK. By using a generic .NET class library, you can share it not only with other applications based on the Windows App SDK but also with every other project type supported by .NET – web apps, cloud services, mobile apps, and so on.
When you choose the Class library project type in Visual Studio, there are two options to choose from:
- A specific .NET version (for example, .NET 5 or .NET 6)
- .NET Standard
The first option is the best choice when you're planning to share this library with any other project that is using the new .NET runtime. This choice will give you access to the widest surface of APIs and features, such as the latest additions to the C# language.
Alternatively, .NET Standard is the best choice when you're going to share this library with older platforms that are based on other flavors of the .NET runtime that were created before the unification journey started with .NET 5. In fact, .NET Standard was created when developers had the need to share code across different implementations of .NET, such as Mono (used by Xamarin and the first release of Blazor), .NET Core, and the full .NET Framework. .NET Standard defines a set of APIs through a contract, which must be agreed by all the various implementations of the platform. When a platform implements a specific revision of a contract, it means that it implements all the APIs that are part of the revision.
The currently most widely adopted revisions of .NET Standard are 2.0 and 2.1:
- 2.0 is the best choice when you need to share your code with .NET Framework applications.
- 2.1 is the best choice when supporting .NET Framework isn't a requirement but you need to share your code with a .NET Core or Xamarin application.
.NET Standard has played a critical role in the .NET ecosystem in the past. However, in the long-term future, as developers will gradually move their .NET projects to the new .NET runtime introduced with .NET 5, it won't be required anymore. You will just need to target the lowest version of the .NET runtime across all your projects. For example, if you need to share code between a WinUI application based on .NET 6, a web project based on .NET 7, and a mobile application based on .NET 8, it will be enough to create a class library that targets .NET 6.0 to share it across all of them.
