12

Where to store binaries needed for automatic builds on Team System? Are you storing them along with the code in the SCM or someplace else? Is having a big amount of binaries in SCM causing any performance issues with source controol?

There is a need to be able to revert to earlier version of some external library in order to fix bugs in released version, however the versions are not compatible. Branching would do the trick, but I think that storing binaries along with the code is anti-pattern.

Any suggetions are welcome.

Daniel Dyson
  • 13,192
  • 6
  • 42
  • 73
Petr Macek
  • 1,493
  • 1
  • 15
  • 19

5 Answers5

3

Both Nexus and Artifactory currently support storage for binary artifacts and dependencies used in .net development. For TFS build and integration to Visual Studio using NuGet packages, you can review this blog.

pacease
  • 31
  • 2
  • 1
    The blog link is now http://www.jfrog.com/continuous-integration-using-tfs-nuget-artifactory/ – Jason Mar 04 '15 at 00:26
1

I've always used svn:externals for this in the past, as described by cringe. But it's slow to update in a local working copy. I've kicked off an open source project with a couple of friends to try and solve this issue, which is still at a very early stage, but if this is a problem you're interested in you might want to keep an eye on it (or even help with it). It's called Refix and is hosted on CodePlex.

Community
  • 1
  • 1
David M
  • 71,481
  • 13
  • 158
  • 186
0

We've always stored external binary dependencies along with source code, images, build scripts and all other artifacts needed to build a solution together in the version control system(VCS). That's what a VCS i really good at, and it ensures that we have the proper version of all necessary artifacts available for any version of our build, even the branches.

I'm curious: Why would you consider this an anti-pattern?

Per-Frode Pedersen
  • 1,027
  • 1
  • 6
  • 15
  • 3
    Increasingly, teams are switching to DVCS (e.g. Git, Mercurial), where each user has the entire repo history locally. If you have a build that depends on large or oft-changing binaries, this is an anti-pattern because it forces every repo to have local *copies* of every binary ever used (even *transitively* used!) instead of *references* to the direct dependencies. This can be considered an antipattern if it discourages teams from breaking their codebase into otherwise logically-independent components hosted in separate repos. – Mickalot Jun 21 '14 at 14:51
  • 1
    In the 4 years since this reply Git and NuGet has been introduced. These two tools combined create a much better dependency management and dependency history than the centralized repositories of old. I completely agree that my original approach should not be used if you have these kind of tools available. – Per-Frode Pedersen Jul 01 '14 at 13:48
0

Subversion for example has the svn:externals that could be used to import the contents of another directory with your libraries. The external could be pinned to a specific revision. For me that is a better way and you avoid nested working copies.

cringe
  • 13,401
  • 15
  • 69
  • 102
0

(I know this is an old question, but my typically-Java-based team is doing a bit of .NET work and asking the same questions right now, and here's what we've found.)

If you're using a DVCS system like Git, then you're absolutely right that you may experience performance problems if you check those libraries into source control. As a point of reference, we transitioned several large projects (2-5GB) with checked-in binaries from Perforce to Git. The performance of the imported Git repos (using Git 1.9 on beefy Windows boxes using SSDs) was unsuitably slow for development. We tweaked our build to pull most of those dependencies from a private Nexus instance, and the significantly slimmer repos (50-200MB of source) seem to be performing well.

If you already have a Nexus instance available to you, there's nothing stopping you from using it to store .NET artifacts -- as far as Nexus is concerned, an artifact is just a file. If you zip up your DLLs and config files and whatnot into a single file, Nexus is happy to host that as a versioned artifact, and you can download/unzip it to the right spot when you need it. (I haven't used Artifactory, so I can't comment on what it does.)

If you want something that specifically integrates with VisualStudio (or MonoDevelop), then NuGet seems to be the emerging answer now.

By default, there's a central NuGet feed with no access restrictions on reading. For hosting, it looks like you can submit OSS/public binaries to be hosted there, and if you want to host proprietary/private binaries, there are instructions for setting up your own private NuGet feed.

If you have the Pro version of Nexus, it claims to host .NET artifacts and allow access through NuGet, but I have no experience using it.

Mickalot
  • 2,431
  • 3
  • 22
  • 23