technology from back to front

WebGAC: Minding your .NET Dependencies

Managing binary dependencies in .NET can be a complicated task. For small projects, checking the dependencies into source control tends to work just fine. So does requesting that all developers have various binaries available in their GAC. Grow much bigger, or add more projects, and managing that starts to get very difficult.

The Java world has had a solution to this problem for a long time, in the form of Maven and Ivy. Remote servers store the binaries, and the build tool automatically downloads them on demand. WebGAC adds the core of this functionality to .NET, but without requiring you to switch build tools, or maintain a separate configuration file. Dependencies are specified just the same way as normal, but if you don’t have them when building your project, WebGAC will fetch them for you automatically.

WebGAC is available at Browse over there for more information and installation instructions, or continue reading here for more details.

The Remote Server

A WebGAC remote server is as simple as an Apache HTTP server running the DAV extensions. The DAV extensions provide the ability to query (in a structured form) for directory lists, and to upload new files remotely.

WebGAC in MSBuild and Visual Studio

To do its thing, WebGAC requires that a custom Import of targets is added to each project. This is as simple as adding the following block:

<Import Project="$(MSBuildExtensionsPath)\WebGAC\WebGAC.targets" />

This import adds all the necessary hooks for doing remote dependency resolution using your project’s normal references. Any missing assemblies will be automatically downloaded and inserted into your build.

The WebGAC Visual Studio add-in provides mechanisms for configuring the WebGAC extension (eg, setting up remote servers), browsing the remote servers and uploading binaries to the remote servers.

The imported MSBuild targets file also includes targets that allow the assembly produced by the current project to be uploaded to a WebGAC – thus allowing for the release of binaries either from developer machines or from a continuous integration environment.

The Gory Details

This section discusses how WebGAC actually does what it does. If you’re just interested in using WebGAC, feel free to skip it.

As a standard property within the MSBuild environment for a .NET project, the AssemblySearchPaths property is defined as:


The WebGAC targets import overrides this, by inserting a {WebGAC} target after the {GAC} element. It also overrides the ResolveAssemblyReferencesDependsOn variable (which defines the standard set of tasks to execute when preparing Assembly Resolution) to execute the target AddWebGACAssemblySearchPaths. This target will query it’s own cache (and any configured remote web servers) for the project’s references. If they are available via the WebGAC, it will download the files and insert the local cache directories into the search paths. MSBuild and Visual Studio will treat these new paths as if they came from any other standard part of the build system, and incorporate them transparently into the build. Visual Studio will even treat the assemblies as if they came from the GAC!

If WebGAC sounds like it could be useful to you on your .NET project, head over to There is even a pre-built installer to get you going quickly!

  1. [...] and install them in their local GAC. You see the troubles coming in that setup, don’t you? WebGAC to the rescue here. It’s essentially GAC shared by WebDAV and enables clients to fetch [...]


− 2 = one

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us