Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
.NET dependency management: `dotnet add package` vs. Paket?
Many older projects (i.e., older than 5 years) provide instructions to the Paket .NET dependency manager (e.g., Suave), so I started digging into it, got confused, then gave up for while because errors kept cropping up and I just wanted to make progress.
I reached a point in my project where I have to add packages properly (instead of just pulling them in on the CLI when testing), so I did a search for the term dotnet add external package project to solution where the most prominent results were:
-
[Microsoft Learn] Install and manage NuGet packages with the
dotnetCLI -
[Microsoft Learn]
dotnet add packagecommand - .NET CLI
After reading, dotnet add package looks exactly what Paket is doing: adding NuGet packages to a .NET project. Am I missing something?
edit: Suave's NuGet page seems to confirm that they provide the same functionality, but, unlike the .NET CLI instructions, there is a warning below the Paket ones, implying that it is a third-party solution:
The NuGet Team does not provide support for this client. Please contact its maintainers for support.
1 answer
Based on what I know so far, there is no difference.
Paket has been created more than 10 years ago to address (perceived?) shortcomings of NuGet. (Reading the .NET history made my head spin, and looks like things started to speed up significantly after the 2020s.)
Paket has features that may be more appealing to some:
-
add dependencies not in NuGet, such as GitHub repos.
Most questions I've seen where people wanted to achieve the same thing (e.g., 1, 2), the reply was that those projects should be converted to NuGet packages and uploaded there (unless I misread something..). Perhaps Paket does the same thing in the background, but this step is automated then.
-
creates an external lock file that can be added to version control.
dotnet add packagecan also add specific versions of packages in the project files (e.g.,.csproj,.fsproj), but not sure how it compares to using a lock file. Perhaps there is greater granularity?
There is also an answer posted in the Stackoverflow thread:
NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications;
dotnet add packagedoes essentially the same thing.Paket is a third-party package manager with somewhat different semantics.
I reached a point in my project where I have to add packages properly (instead of just pulling them in on the CLI when testing)
There is only one way that packages get added to a .NET project via NuGet, and that is by recording them in its
.csprojfile. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing some basic research into how package management works in .NET and how it accomplishes this?there's a historical explanation: Paket has been created more than 10 years ago, when there probably wasn't any native dependency management solution
More basic research shows that NuGet has been around for over 13 years at this point.
Further basic research explains that Paket was created to address what was perceived as various omissions or flaws in NuGet.
You almost certainly neither want nor need to use Paket, unless it offers something that NuGet lacks that you absolutely cannot live without.
0 comment threads
1 comment thread