This project is read-only.

Project Description

Refix solves the problem of binary dependency management in .NET solutions. Refix is the only binary you'll need to commit to your source code repository!

Short of installing all dependent binaries in the GAC, dependency management is something with which many .NET development teams struggle. When many .NET projects use continuous integration, often with a build that may run on one of several build agents, making sure that all the dependencies are in place is a complex problem. Some achieve it by committing third-party binaries with their source code - at the more organised end of the spectrum, this could take the form of a central Subversion-based repository of binaries included via an svn:externals link for example. But this approach is slow, and slows down every commit and update. The aim in our view should always be that a developer can get a fresh copy of a project from source control and just build it. .NET promised Microsoft platform developers an end to DLL hell. Certainly, multiple versions of a DLL can be installed side-by-side in the GAC and accessed independently. But for those wanting to bundle dependencies with their application for a true XCopy deployment, this is not an option.

We were motivated to write Refix by a Subversion-based solution that was getting slower and slower to update, and where two third party libraries introduced a clash between two versions of a DLL each depended on. "We can deal with this using an assembly binding redirect, as we know the newer version to be backwardly compatible with the old. But shouldn't there be a tool that can sort this all out for us?" we asked ourselves. Refix does just that. The main components of Refix are:
  • A repository of third-party binaries, which exists locally but also as part of a hierarchy leading ultimately to
  • A command line tool to "Refixize" a solution, and manually perform tasks if for whatever reason Refix is not integrated into a solution.
  • MSBuild projects to run at the beginning and end of a solution build that integrate the necessary Refix steps.
The documentation page describes each of these in more detail, and walks you through how to get started with Refix in more detail, but brief instructions can be found below. If you want to see a project that has Refix integrated into it, you could do worse than to download Refix's own source code from this site. We hope you'll find that it will download and build first time!

Source & continuous integration

You can download the Refix source code from this site. We have a TeamCity continuous integration build hosted by CodeBetter at:

Installation and getting started

Download the console application zip, and extract to a folder of your choice. Edit the config file to specify the folder where you want your local repository to reside. Optionally, add the installation folder to your PATH environment variable. One simple configuration is to create a Refix folder in your normal development working folder, and a Repo folder underneath it. Copy the console application to the Refix folder, add it to your path, and then set the repository location either using the RFX_REPO environment variable, or a setting in the console application's configuration file (the environment variable takes precedence if you do both).

The console application is preconfigured to point to a remote Refix repository at This, like the software, is in BETA status and should therefore be treated with the caution with whcih you treat all pre-release software. You can test the installation by running the version command from the command prompt, then getting the current log4net version into your local repository:

Screen shot 2010-06-19 at 14.15.24.png

Repository-related usage scenarios

These commands maintain the assembly binaries and their metadata within the local repository folder.

Register an assembly in your local repository

Run the command:

rfx reg[ister] <filename>
(e.g. rfx register nunit.framework.dll)
This adds the binary, and any recognised associated files, to the local repository, and inserts values into the assembly's version.xml file.

Mark a compatible alternative version

Run the command:

rfx alt[ernative] <assembly> <version> <compatibleversion>
(e.g. rfx alternative nunit.framework 2.5.2 2.5.2+)
The command accepts the following wildcards:
  • 2.5.* matches any version beginning 2.5.
  • 2.5.2+ matches any version whose third part is greater than or equal to 2.

Dependency resolution usage scenarios

These commands inspect a project, determine a compatible set of assembly versions, and rewrite project and config files as necessary to allow the solution to build against those files.

Preparing a solution to build

Run the prebuild command from the solution's root folder:

rfx pre[olve] [SOLUTION]
The optional SOLUTION parameter, here and below, indicates that the solution file name must be specified if the current folder contains more than one .sln file.

Integrating Refix into a solution

Run the solution command from the solution's root folder:

rfx [sln|solution] [SOLUTION]
If you are happy with the integration, then you should re-run this command and immediately follow it with the fix command to make the changes permanent.

rfx fix [SOLUTION]

Cleaning up after Refix

Run the following command from the solution's root folder:

rfx clean -a [SOLUTION]
Full help on these, or any commands is available from the command line by typing rfx help. All commands accept a verbose option (-v or --verbose) to show more informaton as they run, or a quiet option (-q or --quiet) to hide all non-error messages.

Last edited Sep 15, 2010 at 7:38 AM by davidmus, version 12