Managing your dependencies with NuGet can be just fine.
Unless you want some of these be compiled locally.
For example, imagine that you have a complicated dependency graph, and you've just modified a source of one of the assemblies. Or you just want the freshest bits from the source control. Now you want to use the local version in your project, since you don't want to wait till your modification is accepted and released as a NuGet package. At the same time, you want to use the other dependencies managed for you by NuGet, plus merge the recent updates to the ones that you build locally. Welcome back to dependency nightmares.
This could be even worse than the pre-NuGet era. If only Ripple didn't exist.
Ripple was created for scenarios like this. Well, not exactly, but at least it can save you from Dependency Hell. What's even better, Ripple will do a lot of things for you so that all your solutions will have the freshest bits from NuGet when the local source is missing, and locally built assemblies conveniently put into the NuGet package folders.
In other words, Ripple is NuGet's best friend.
For a good introduction to Ripple (and its requirements), check the Ian Battersby's Ripple-tastic! post. Ian gives an example of a "targeted" rippling -- from one to another solution. However, I have discovered it's more fun to just "ripple around" -- shoot "ripple local" without the "from" and "to" pieces. This way Ripple just fixes and updates everything it can.
There are many Ripple commands available. Here is the (incomplete) list of them, as of today.
- Clean -- just clean a particular solution, or all solutions. Can clean packages, project outputs, or both.
- Float -- makes the package "floating" -- marked as to be updated by Ripple.
- GitIgnore -- Lists or adds values to the .gitignore file.
- History -- write the list of packages to the dependency-history.txt file.
- Init -- Creates a basic ripple.config file and opens it in an editor, removes packages from Git and adds their folder to .gitignore
- List -- for each solution, outputs the list of projects with their dependencies and published packages.
- Local -- you better try it yourself with a verbose flag and watch the output.
- LocalNuget -- Creates the nuget files locally
- Lock -- opposite to Float, locks a nuget to prevent it from being automatically updated from the Update command.
- Publish -- Builds and pushes all the nuspec files for a solution(s) to nuget.org.
- Restore -- another important command, interacts with nuget to restore all the nuget dependencies in a solution tree.
- Update -- gets the latest NuGets (or just lets you preview them). As I understand, either Restore or Update is used as part of the Local command execution.
- UseTheirs -- Does a 'use theirs' merge on all the project and packages file in a solution.
- WhereAmI -- Tells you where ripple thinks the root folder is at.
You can see that this is a great piece of functionality for those who works actively with OSS dependencies. It is opinionated, in the ForUsByUs way, but you can happily use it in non-Fubu projects. The only annoying limitation for me is that you should keep your projects in the same folder, but it's not annoying enough for a pull request.
Ripple is included in the buildsupport submodule if you get the source of any Fubu project.