Description
Is your feature request related to a problem? Please describe.
The use of generated static types in UnitsNet offers many advantages, such as strong typing and performance. However, one notable drawback is the lack of extensibility. Many applications operate in specialized domains with unique quantities or units that are not suitable for inclusion in the general-purpose library.
These gaps range from obscure units missing from existing quantities to entirely missing quantities. While UnitsNet does provide an extension mechanism (see Extending with Custom Units), it is currently experimental. The usage pattern differs significantly from that of the built-in units, leading to increased complexity and a less seamless developer experience.
Describe the solution you'd like
I would love to see a more first-class and streamlined extension mechanism — one that enables users to add custom units in the same way built-in units are added to UnitsNet.
For example, users could create a custom class library that includes:
- A reference to the standard UnitsNet NuGet package.
- A reference to a new design-time NuGet package, such as UnitsNet.Design, which provides the tools and templates needed to define custom quantities and units.
This would ideally require a restructuring of the UnitsNet codebase, where core abstractions and base classes are separated into a dedicated core project, and unit implementations live in separate subprojects. This would also improve modularity and maintainability.
An example of a custom extension project might look like:
<PackageReference Include="Microsoft.UnitsNet.Core" Version="..." />
<PackageReference Include="Microsoft.UnitsNet.Design" Version="...">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
This custom extension could then be packaged and distributed via NuGet for reuse across multiple projects within the same domain.
Describe alternatives you've considered
The only viable solution at present is to fork the UnitsNet repository, add the required custom units directly, and maintain the fork manually — occasionally merging updates from the upstream repository. This approach introduces significant maintenance overhead and discourages modular reuse.
Additional context
I haven’t performed deep research into the feasibility of this suggestion, and I understand there may be technical or architectural constraints. However, I wanted to share this feedback based on my experience and highlight a long-standing challenge in working with UnitsNet in domain-specific contexts.
I’m not attached to any specific implementation — the goal is simply to make UnitsNet more extensible in a way that aligns with how it already works. If there are concerns or constraints I haven’t considered, I’d really appreciate your thoughts.