.NET Zone is brought to you in partnership with:

Software developer and frequent open-source contributor. Writing mostly for .NET, but also Java and C/C++. Really likes fiddling with data, texts especially, so he frequently finds himself working on databases or search engines, usually combining both. Itamar is a DZone MVB and is not an employee of DZone and has posted 31 posts at DZone. You can read more from them at their website. View Full User Profile

Pro Tip: Don’t Push Binaries To Source Control, Use NuGet Wisely Instead

  • submit to reddit

If you use nuget, then you probably are familiar with the packages folder that takes forever to update in your source control repository. Whenever you or someone in your team updates a package, committing and pushing it takes forever, and then everyone updating their local copies have to wait as well for it to download again.

In most scenarios there is absolutely no need for going through that torture. Instead of pushing binaries to your source control repository, you can just get those packages dynamically when building. Here are the steps to make this happen in an existing solution - it is even easier to do for a new one:

1. Copy Nuget.exe (you can get it from their site) to a \Tools folder under your solution

2. Go to Project -> ProjectName properies -> Build Events and add this pre-build action:

$(ProjectDir)..\Tools\Nuget.exe install $(ProjectDir)packages.config -o $(ProjectDir)..\Packages

3. Save and close VS. Delete the packages folder and commit.

4. Add the packages folder to gitignore. If you are not using git, start using it already.

5. Open the solution again, do a Clean Solution and build, see if nothing breaks. It shouldn't. Now push the change and relax.

Note this methods preserves the package version used, and when someone updates the version number all that is left to do is push a simple change to a text file and that's about it.


Published at DZone with permission of Itamar Syn-hershko, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)