In the Java world there are several ways of handling dependencies between project components in a shared development environment. Maven is a generic build tool that creates a standardized way of creating, building and publishing component artifacts. Dependencies between the different components are declared in a Maven build file and Maven automatically downloads the dependencies and all transient dependencies recursively from local or public repositories. Repositories can be local to a particular developer, department or enterprise; or they can be public, available to the development community at large. Ivy is another utility which focus solely on dependency management. It is positioned as the lean and simple alternative to Maven which focus only on the dependency aspects and that integrates well with Ant (the generic java build tool).
For .NET based solutions there does not seem to be neither a Maven nor Ivy style dependency management system for development. This article outlines a solution to dependency management in the .NET world that has been inspired by the Maven and Ivy.
Outline
The Global Assembly Cache (GAC) is where .NET dependencies are handled. Assemblies installed in the GAC are made available for fulfilling the dependencies of DLL’s inside or outside of the GAC. The GAC does not, however, reach outside one machine (real or virtual). In order to handle dependencies in a team development environment, where dependencies are shared, a distributed version of the GAC is envisioned, the Universal Assembly Cache or UAC.
The UAC is a repository with layout identical to the GAC but where dependencies can be downloaded using HTTP or FTP protocols and published using FTP or Web DAV. Repositories can be chained and when retrieving dependencies, chained repositories are searched in sequence one after another.
Command line tools
As for the GAC the UAC should have command line tools to manage the UAC. The command line tools would be used to download a DLL and all its dependencies not fulfilled by what is already installed in the GAC and then install the downloaded libraries. Likewise a DLL found in the file system or in the GAC could be published to the UAC and thus made available to other parties.
In addition MS DOS and command line tools the same functionality should be available as .NET PowerShell cmdlets. For mono on Linux, commands in a suitable script langue should be considered.
Visual studio Add-On
To facilitate dependency management during development a Visual studio add-on is used to check the references of each project in the solution. At startup, on demand or optionally for each build, unresolved references are searched for in the UAC and if found, installed in the GAC or put in a common solution folder. Ideally the Add-On is integrated as an additional tab in the Add Reference dialogue.
Similarly to Ivy and Maven, Visual Studio references to a given DLL can be to a specific version of a DLL or they can be according to some kind of dependency resolving strategy (Ivy latest strategy). As an example, the latest minor version of a component for a given major version can always be looked for. Switching to a new major version should be done manually since it is assumed this would nearly always break the build.
Publishing a DLL should not be possible through the add-on since publishing should be done in a more controlled environment than a developer desktop . Instead publishing should be done as part of an automated build system
Build Tools
In order to accommodate build engines all functionality required for a build should be replicated in NAnt and MS Build tasks. In addition there should be tasks for publishing DLL’s to the repository.