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.

Answer 3

Currently it looks like I'm going to have to write something which will recursivly go through the folders and msbuild any proj files, record if it will suceed or not using a msbuild logger.

Look through the folders again find any dlls with the same name copy the new one in.

Go through the folders again and re-run MS build and see what fails when compared with the first.

Answer 4

Could you add a post-build step to the included-but-not-really-included projects to dump the DLLs to a prearranged location? From there, you could add a pre-build step in the dependant projects to grab new DLLs from said location. Definitely not best practice, but it should get the job done.

Answer 5

An easier approach would be to create a solution that contains all the projects you need, modify the references between them to use project references, change the projects so their output folders all point to the same directory, and then setup the project references so that "Copy Local" is set to false.

Then all you need to do is build the solution (either in VS or on the command line via msbuild).

The build result would be a single folder that has all the files you need in it, and every project would always have up to date references.