Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Must I still keep my 3rd party library binaries in source control?

Now that I'm using NuGet to add/update my required references, is it possible to only add packages.config to source control and have the .dlls added at build time?

Normally, like described in this related question, I store third party dependencies in a folder under the solution root and check them in to source control.

We're currently not using any custom build tools or scripts: just VisualStudio's default build with the .sln file.

like image 651
hometoast Avatar asked Dec 16 '10 12:12

hometoast


People also ask

Where are third party libraries stored?

Third party libraries can go anywhere you want, as long as you make sure that both the compiler and the compiled program can find the files that they need. So you can go wild with organizing your files in whatever you want, as long as you make sure that you tell this to the compiler and the compiled program.

Which file is used to include the third party libraries?

Third-party libraries A third-party (or “contributed”) library is a chunk of Javascript code, usually contained in a single . js file, designed to work with p5.

How do I use third party library in Visual Studio?

To use a library, just #include it. Visual Studio will automatically add the library path to your project settings and copy the DLL to your solution folder.

What is a third party library in web development?

In computer programming, a third-party software component is a reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform.


1 Answers

Yes you can! http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

The current NuGet workflow has always been to commit the Packages folder into source control. The reasoning is that it matches what developers typically do when they don't have NuGet: they create a ‘Lib' or ‘ExternalDependencies' folder, dump binaries into there and commit them to source control to allow others to build.

While this has worked fine for some users, we have also heard from many that committing packages into source control is not what they want to do. When using a DVCS like Mercurial or Git, committing binaries can grow the repository size like crazy over time, making cloning more and more painful. In fact, this has been one of the top requests on NuGet our issue tracker.

The good news is that NuGet now offers a workflow which goes a long way to solving this problem. It isn't 100% automated yet, but with some minimal pain you can set up your project to do this...

like image 107
davidfowl Avatar answered Sep 27 '22 22:09

davidfowl