A lot has been said about storing binaries inside project's repository. Does this mean I can't share my frustration (caused by my recent experience)? Definitely, not.
Don't to do this!
That's it, I'm done with the emotional part.
I'm not talking here about NHibernate, or NUnit or fancy P&P tools you downloaded from the Codeplex to impress girls. Those are solid and (usually) well-tested libraries that don't change frequently. And even when they do, you are not forced to adopt the newest version.
I'm primarily talking about so-named "frameworks" and "integration middleware" your fellow co-workers next door, right behind the water cooler, are developing . Regardless of how qualified they are, deadlines and ever-changing requirements will force them to push (and force you to use) updates at random moments. In other words, their code is as unpredictable and crappy as yours.
So you'd better be prepared and react right after these changes are checked in.
Few obvious points about having dlls in your repository:
- You can’t get any meaningful change history from your “Binaries” folder, especially if you don’t bother writing good check-in comments.
- You can’t merge automatically.
- It’s impossible to increment in small steps, you have to check in whole dll.
- You will multiply your problems if you reference other project that also uses your binary dependencies.
What arguments will be probably used to sneak THEIR libs into your precious repository:
We don't want our changes to break your code. Just grab a fresh version whenever we consider it “non-breaking” enough.
Well, if you are creating a framework, you must not introduce any breaking changes. If you just create remote proxies for your corporate distributed system and interface changes in a non-backwards compatible manner, how will not breaking the build help you?
We have multiple consumers within the organization. We cannot have them all in our solution.
You don't have to. Consumers will have to refer to your repository using something similar to SVN Externals. You will get notified by CI server when you break someone's build.
But this way others will be able to access our code!
Give read-only access to everyone who is involved within the organization, you won't be able to keep it secret anyway (at least not with .NET).
We will use separate branches to give each consumer it’s special version and give it as set of dlls. You don’t have to bother, we’ll take care of everything.
You probably don’t know what you’re diving into. Even leaving aside the Open-Closed Principle, which strongly discourages that style, are you really going to maintain these branches for the whole lifetime of their corresponding projects?