2

I have a C# solution containing different projects. On those projects, I have some normal nuget packages like Newtonsoft.Json, EntityFramework , etc. But when I checkout my source on another machine, and build it, it won't copy the Dllsenter image description here

I've committed the whole solution folder to git and I can see the package folder and the contents in Bitbucket. What did I do wrong?

P.S: I know that I can run below to restore my packages, but that is a big pain. P.S.S: I've searched and saw this and this. I am looking for a way to prevent it from happening again

nuget install packages.config
Community
  • 1
  • 1
Ashkan S
  • 10,464
  • 6
  • 51
  • 80
  • 1
    Is there any particular reason you don't want nuget to automatically restore missing packets on build? – Manfred Radlwimmer Aug 05 '16 at 11:23
  • @ManfredRadlwimmer no I am ok with any thing that can put the dlls on their place. Shall I remove package folder from git then? – Ashkan S Aug 05 '16 at 11:25
  • 1
    In my opinion you shouldn't be storing your packages in any repository. Just let them be restored as and when required. Nuget will cache the packages on the box once it restores and on subsequent uses it will use the package from the cache. For example using the same packages in any other project. Also you can write a .bat file which you can just double click and it will restore the packages. – The Shooter Aug 05 '16 at 11:27
  • @TheShooter I disagree. In this day and age of open source projects being dumped or forked; of Microsoft, Apple and Google ditching one tech or service only to be replaced by another; there is no guarantee that you can't replicate your build in 12 months time when you are dependent on a unknown quantity in the cloud. Ensuring that all artifacts are at your disposal in SCM is the only sure guarantee that you can reproduce a build for auditors with the minimum dependencies on 3rd party systems. –  Aug 05 '16 at 11:33
  • @MickyD That's a very pessimistic view, and fairly easily mitigated, as I've written in my answer. – Neil Barnwell Aug 05 '16 at 11:37
  • 1
    @MickyD: As #Neil Barnwell has pointed out in his answer rather than checking-in packages in scm one should consider setting up in premises nuget server. it can be a http based server or fileshare based server as we are using a http based nuget server in our office. – The Shooter Aug 05 '16 at 11:41
  • @NeilBarnwell It's a realistic and due-diligent view. Considering the cost of disk space, the option of not-to-commit is lazy; risky and short-sighted. (doh, just saw your edit in your post +1) –  Aug 05 '16 at 11:42
  • @TheShooter Yes, I like that idea, I had not considered that. A private corporate NuGet repo that contains just the stuff we need, and that can be backed up is a jolly good idea! Thanks :) –  Aug 05 '16 at 11:43

1 Answers1

3

The idiomatic way to use NuGet (unlike npm, for example, where it's typical to commit node_packages) is to commit only your packages.config. Visual Studio will detect missing packages in the packages/ folder and restore them on build, and nuget restore at the command line will do the same.

The reason for this is that binaries are larger than text files, and not diffable (i.e. storing a delta isn't possible). I'm not sure git even works that way as svn did, but the authors of nuget aren't writing just for those using git.

If you're concerned about packages going missing, I have two points:

  1. Nuget.org are quite careful about that not being possible. They've set things up so that packages can only be soft-deleted, which means a restore can see those versions, while a nuget install will not.
  2. Many people run their own internal package server (like Klondike) which acts as a kind of proxy to nuget.org. This is also beneficial if you want to package internal libraries and distribute them in your projects using nuget, without publishing them to the internets.
Neil Barnwell
  • 41,080
  • 29
  • 148
  • 220
  • Yes I like point #2 as [TheShooter](http://stackoverflow.com/users/6399610/the-shooter) mentioned too. +1 –  Aug 05 '16 at 11:45
  • Thanks @Neil Barnwell, very good considerations, I will apply them later. But first, based on your answer, if I ignored the package folder from my git repo, I wouldn't have any problems. right? I will try it then :) (Y) – Ashkan S Aug 05 '16 at 13:37