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.
Post History
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 l...
Answer
#3: Post edited
by
toraritte
·
2024-03-26T12:41:20Z (about 1 month ago)
[Answer posted in the Stackoverflow thread](https://stackoverflow.com/a/78216226/1498178):- > NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications; `dotnet add package` does 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 `.csproj` file. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing [some basic research](https://learn.microsoft.com/nuget/what-is-nuget) 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](https://en.wikipedia.org/wiki/NuGet) shows that NuGet has been around for over 13 years at this point.
- >
- > [Further basic research](https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config) 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.
- Based on what I know so far, there is no difference.
- [Paket][1] 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][1] 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](https://stackoverflow.com/questions/41806018/asp-net-core-application-that-references-a-project-in-another-git-repository), [2](https://stackoverflow.com/questions/60396634/git-use-solution-from-another-repository)), 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 package` can 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?
- [1]: https://fsprojects.github.io/Paket/
- [2]: https://suave.io/index.html
- [3]: https://stackoverflow.com/questions/77467563/how-to-automatically-add-package-reference-into-project-file-after-installing-n
- There is also [an answer posted in the Stackoverflow thread](https://stackoverflow.com/a/78216226/1498178):
- > NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications; `dotnet add package` does 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 `.csproj` file. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing [some basic research](https://learn.microsoft.com/nuget/what-is-nuget) 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](https://en.wikipedia.org/wiki/NuGet) shows that NuGet has been around for over 13 years at this point.
- >
- > [Further basic research](https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config) 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.
#2: Post edited
by
toraritte
·
2024-03-26T12:29:55Z (about 1 month ago)
Answer posted in [the Stackoverflow thread](https://stackoverflow.com/questions/78210598/net-dependency-management-dotnet-add-package-vs-paket):- > NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications; `dotnet add package` does 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 `.csproj` file. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing [some basic research](https://learn.microsoft.com/nuget/what-is-nuget) 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](https://en.wikipedia.org/wiki/NuGet) shows that NuGet has been around for over 13 years at this point.
- >
- > [Further basic research](https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config) 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.
- [Answer posted in the Stackoverflow thread](https://stackoverflow.com/a/78216226/1498178):
- > NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications; `dotnet add package` does 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 `.csproj` file. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing [some basic research](https://learn.microsoft.com/nuget/what-is-nuget) 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](https://en.wikipedia.org/wiki/NuGet) shows that NuGet has been around for over 13 years at this point.
- >
- > [Further basic research](https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config) 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.
#1: Initial revision
by
toraritte
·
2024-03-26T12:28:07Z (about 1 month ago)
Answer posted in [the Stackoverflow thread](https://stackoverflow.com/questions/78210598/net-dependency-management-dotnet-add-package-vs-paket): > NuGet is created by Microsoft and always has been the default, simple, built-in package manager for .NET applications; `dotnet add package` does 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 `.csproj` file. It doesn't matter how you do it, via GUI or CLI, that's it. Have you considered doing [some basic research](https://learn.microsoft.com/nuget/what-is-nuget) 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](https://en.wikipedia.org/wiki/NuGet) shows that NuGet has been around for over 13 years at this point. > > [Further basic research](https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config) 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.