Library Organization


More or less, over time, we have developed about 40 libraries. We plan to migrate these to .NET 5.
We are completely reexamining these library projects to take advantage of .NET 5 features and to eliminate any dependencies they might have on each other.

Simple but deep question: what is the best way to organize libraries for .NET 5?
Should we build many small or several large libraries?
Should we try to achieve dependency separation or should we establish chains of dependency?
Does .NET 5 itself promote one decision over another?
Is there any guidance on these issues in published form?

Microsoft Technologies based on the .NET software framework.
3,347 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Karen Payne MVP 35,031 Reputation points

    Hello @Anonymous

    There is no one path for migrating although there are recommendations (see develop a plan) and this is not all dependent on .NET 5 Framework. When possible (and this is not .NET 5 specific) use generics for shared libraries you which may currently be doing but if not this is a time to consider both generics and Interfaces.

    On this page information is presented to considerations for piece by piece project migration Organize your project to support both .NET Framework and .NET Core

    Regarding small or several large libraries, it's always wise to plan for smaller projects but that is not always possible so that is where planning out namespaces for functionality comes into play which means one can go small or large.

    Then there are considerations will code need to be cross-platform, are there multiple project types e.g. ASP.NET Core, WPF, Windows Forms, xamarin etc. then there is data interactions, going back to project type and platform (where web project types of course are easier in many cases).

    Things to look at for .NET 5 specifically, performance improvements as laid out here rather than language features per-say. A great way to bench mark is to have current code against migration code using BenchmarkDotNet coupled with unit test.

    Another consideration is to create on-prem NuGet packages, sticking with the above, keep them small when possible. Microsoft for sometime now has been going small with libraries.

    The above may not provided all possible answers to your question and is not intended to, the intent is for you to have a plan which may change over time while if attempting to follow one path "just because" may lead to frustration and additional hours backtracking to go a different direction.

    0 comments No comments