When I first joined up with my current job, our Team Foundation Server (TFS) source control was set up as a single repository, serving a single solution, with somewhere between 35-40 projects inside of it. NuGet wasn't being used because the developer hired just before me had issues getting projects to compile when NuGet was managing the packages. This meant that, by the time I joined the team, all the packages were sitting in a library folder and checked into source control, so that they could be downloaded with the solution and projects--only this occasionally meant re-referencing things because sometimes the reference would be dropped, or would fail to find the file through some pathing issue.

When I began a new solution and project from scratch a few months ago, I went with ASP.NET MVC 5 and Web API 2. Visual Studio's project creation wizard allows you to select an MVC 5 project, while adding the Web API to it, but the problem was that certain built-in functionality seemed to be missing from the straight Web API 2 projects. I had to track down and actually install the Microsoft.AspNet.WebApi.HelpPage DLL. Then I ran into an issue where the MVC DLL's were not being found by the compiler despite being on the disk and referenced appropriately. I actually had to run `Update-Package -ProjectName '<NAME_OF_PROJECT>' -Reinstall from the NuGet Package Manager Console in order to get this resolved.

Not the warmest of feelings.

Not that long ago, I started getting more involved in F#, and as a result, I learned a little about Paket:

Paket is a dependency manager for .NET and mono projects, which is designed to work well with NuGet packages and also enables referencing files directly from Git repositories or any HTTP resource. It enables precise and predictable control over what packages the projects within your application reference.

From all of the documentation, it sounded like Paket gave you much finer control over package management for .NET applications, and it seemed like it helped eliminate many of the issues that people have been complaining about with NuGet.

I decided to ask Twitter for the community opinion on switching, and was pelted with responses from enthusiastic community members. Here are just a few of those responses:

@szul Yes - It's much easier to use on the client side, even for non F# projects

— Reed Copsey, Jr. (@ReedCopsey) March 21, 2016

@szul I've had too many not-so-minor issues with nuget as package versions change that I appreciate the dep. management in @PaketManager

— Reed Copsey, Jr. (@ReedCopsey) March 21, 2016

@szul Yes, using for both F# and C# projects.

— Krzysztof Cieślak (@k_cieslak) March 21, 2016

@szul Yes, use it for 36-projects #sharepoint solution and 11-projects #wpf app with Squirrel - for sure with @fsharpMake scripts @sforkmann

— Sergey Tihon (@sergey_tihon) March 21, 2016

@szul yes, moved a large c# project with 100s of deps to paket. Updating core packages dropped from 15-20 minutes to a few seconds.

— Marcio Rinaldi (@marciorinaldi) March 21, 2016

@szul we use it for several projects with in total 250+ projects. Biggest one has 140. #loveit @paketmanager

— Debug King (@DebugKing) March 22, 2016

@szul +1 to @ReedCopsey, been using paket exclusively since Q1 2015. With v3 .net finally catches up with npm/gem, Thanks @sforkmann !!

— Christopher Atkins (@CAIndy) March 22, 2016

@szul @sforkmann since we switched 200-project solution to paket a year ago we've have no headaches with nuget.

— vaskir (@kot_2010) March 22, 2016

I now have Paket implemented in the aforementioned project, and I'll post an update later down the road to tell you how I made out.