Menu
Our projects in TFS are organized like this:
$\DefaultCollection\ProjectName\Source <-- source code goes here $\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here Now that NuGet is on the scene, is there any reason to change our approach and use NuGet's packages folder for dlls that come from NuGet-aware projects? I'm leaning against this because
1) it creates two places one must look for dependencies 2) it leaves us open to one developer updating a package and breaking some dependency
That said, if anyone can report a good reason to start using NuGet in a TFS environment, I will happily present your ideas to my team as if they were my own (joke).
248
Developers typically omit NuGet packages from their source control repositories and rely instead on package restore to reinstall a project's dependencies before a build.
NuGet now has the ability for you to re-download the missing packages as a pre-build step, meaning that you only need to commit your packages. config file (and include nuget.exe in a tools folder). Read Using NuGet Without Committing Packages to Source Control for more details.
NuGet provides the tools developers need for creating, publishing, and consuming packages. Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.
Nuget 1.6 now allows for packages not present to be downloaded dynamically upon build. So you can now check in to source control without the .dlls, but the build itself will pull the correct package.
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
173
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
