Ways of keeping DLLs up to date

Question

I've recently joined a company which has had a number of developers of varying quality work for them over the years.

The projects which have been created rely on outputs from other projects. However instead of creating dependencies in the normal manner and maintaining the code, DLLs have been copied from one place to another and referenced from there.

Is there an easy way to update all of my DLLs under a parent folder to the most recent version of that (by timestamp) accross the whole range of folders ?

So the process in summary:

1. Compile all of the projects and solutions all in a root folder.
2. Find and update all other copies of the output files.
3. Recompile everything and find out what breaks.
4. Update source code and update references.

The problem step is 2.

(I'm quite aware that this may break stuff)

I'm using Visual Studio 2005 and C# to create the DLLs, however I want to update the files rather than the code preferably.

Answer 1

The Microsoft best practice advice is to reference projects rather than DLLs wherever possible.

Project-to-Project References and File References

File references are direct references to assemblies; you create them using the Browse tab of the Add Reference dialog box. Project-to-project references are references to projects containing assemblies; you create them using the Project tab of the Add Reference dialog box.

The advantage of a project-to-project reference is that it creates a dependency between the projects in the build system, so the dependent project will be built if it has changed since the last time the referencing project was built. A file reference does not create a build dependency, so it is possible to build the referencing project without building the dependent project, and the reference can become obsolete (that is, the project can reference a previously built version of the project). This can result in several versions of a single DLL being required in the bin directory, which is not possible. When this conflict occurs, you will see a message such as Warning: the dependency 'file' in project 'project' cannot be copied to the run directory because it would overwrite the reference 'file.'.

You should avoid adding file references to outputs of another project within the same solution, because doing so may cause compilation errors. Instead, use the Projects tab of the Add Reference dialog box to create project-to-project references within the same solution. This makes team development easier by allowing for better management of the class libraries you create in your projects. For more information, see Troubleshooting Broken References and How to: Create and Remove Project Dependencies.

From here.

Answer 2

There are times when project-to-project references don't work. For example build time of projects, or wanting multiple projects to depend on a particular build of a reference, or if testing of the referenced project is complete and you don't want to test things again.

If you have a continuous integration system, and version control, then an alternative is to check in built dlls into version control as part of the CI build. Then reference the dlls (e.g. an external in svn) to the dependent project, this should mean that all your dlls stay up to date.