Dependency Management in .Net

I started my career as a programmer developing on Unix platforms, primarily writing applications in ANSI C and C++.  Due to a number of factors, including the platform dependency of C/C++ libraries, the low-level nature of the language and the immaturity of the Internet, code reuse in the form of reusable libraries wasn’t as prevalent as it is today.  Most of the projects I developed back then didn’t have a lot of external dependencies and the code I reused across projects was checked out and compiled locally as part of my build process.  Then came Java.

When I first started developing in Java, I remember being excited over the level of community surrounding the platform.  The Java platform inspired numerous open source projects, due both to the platform’s architecture and the increasing popularity of the Internet.  The Apache Jakarta Project in particular was a repository for many of the most popular frameworks at the time.  The increase in the use of open source libraries during this time, along with some conditioning from the past, help forge a new approach to dependency management.

The Unix development community had long since established best practices around the use of source control and one of the practices long discouraged was that of checking in binaries and assets generated by your project.  Helping facilitate this practice was Apache’s Ant framework, an XML-based Java build library.  One of the targets provided by Ant was <get> which allowed for the retrieval of files over HTTP.  A typical scenario was to set up an internal site which hosted all the versioned libraries shared by an organization and to use Ant build files to download the libraries locally (if not already present) when compiling the application.  The task used for retrieving the dependencies effectively became the manifest for what was required to reproduce the build represented by a particular version of an application.  The shortcoming of this approach, however, was the lack of standards around setting up distribution repositories and dealing with caching.  Enter Maven.  Maven was a 2nd generation Java build framework which standardized the dependency management process.  Among other things, Maven introduced schema for denoting project dependencies, local caching and recommendations around repository setup and versioning conventions.

Read more: Los Techies
QR:

Posted via email from Jasper-net