.NET is a popular platform for building software systems and apps of all shapes and sizes. The 2016 launch of .NET Core — a free, cross-platform, open source software development framework — has only accelerated .NET's momentum.
Virtually every .NET-based software product that is running or developed currently leverages code reuse. Whether a small desktop or console application or a huge enterprise application, it will contain both original code and reference "borrowed" code in the form of libraries or packages or APIs. We say that our application depends on those external packages, and we call those external packages dependencies.
Code reuse, when applied wisely, decreases time-to-market and increases the overall quality of the product. However, the decision of what components you depend on and how you integrate them can make a huge impact on your development velocity.
As products grow, the management of these external dependencies becomes more and more complex. This post aims to describe some of the artifacts involved in the dependency management of .NET projects and how they interact.
.NET: A Timeline
Artifacts used in dependency management have evolved over time, influenced by the evolution of the .NET Framework, the release of .NET Core, and the emergence of NuGet as the package management solution for .NET projects.
.NET Framework pre-NuGet (before 2010)
Prior to the advent of .NET Core, a project was represented by a .csproj file, and all the dependencies were represented in the same file. If you wanted to reference a third-party library, you had to find it on the web, download it, place it in a folder, and add a project reference to it in the .csproj file.
.NET Framework with NuGet (2010 - 2016)
A project was represented by a .csproj file but the dependencies (including NuGet package references) were kept separately in a packages.config file. Here, you could get your third-party libraries from the NuGet central public collection and transfer your project to another machine without copying the libraries — simply copy the packages.config file and do a package restore.
Initial .NET Core (2015 - 2017)
The first .NET Core projects created in Visual Studio 2015 were represented by an .xproj file (similar to .csproj) and the dependencies (NuGet package references) stored in a project.json file. This approach is now deprecated.
.NET Core is born (2017 - today)
Since Visual Studio 2017, a project has been represented by a .csproj file with dependencies (NuGet package references) listed in the PackageReference section of this file. For some types of projects, dependencies are still kept in that separate packages.config file.