Referencing Assemblies Outside GAC Without Fixing the Path

I'm currently in the process of researching the best development and deployment practices for our team. We have a load of similar code that we're going to start importing into a library of shared assemblies for use across our suite of (web & win) applications. I'm starting to get a clear idea of where I think we should be heading. I'll no doubt have more questions as this refining process progresses.

I'm drawn to the elegance of the structure laid out in W Craig Trader's answer to this question. We're using TFS rather than SVN but the approach applies just as well. Using this approach each dev will have a local workspace containing the latest shared assembly for each major version. Each of these assemblies will be exactly those to be deployed in the target host's GAC.

Each member of the dev team is free to layout their machine as they feel most comfortable so the direc开发者_运维问答tory containing the assemblies to link to during development could easily change from dev to dev. We don't want to store the assemblies in the GAC of the devs' machines. And don't want each dev to have to update the references each time they check a project out or in.

So my question is: is there a way to configure a folder to act like a system-wide assembly store a la GAC? Or is there a way to configure VS2008 to search for assemblies in a particular location?

Going forward we'll configure automated builds/CI, in which case we can fix these things, but in the interim the builds will take place on an individual dev's machine. But even with server-based builds, each dev will want to reference the correct assembly for intellisense and test builds.

Any thoughts or suggestions welcome.

Thanks, Dan

Following some internal discussion is seems we may settle on a fixed location on each Dev's machine. This still doesn't sit well from a personal work space p-o-v but it's the safest approach.

The alternative is write a client side TFS event listener which can augment a project file on check-out and sanitize it on check-in. But I'm not sure how safe that would be.

Cheers, Dan

At my previous job all developers had a R:\ drive which contained all the shared assemblies. With a script the assemblies on the drive were kept up to date by copying them from a network share.

NuGet helps to solve this issue. Build your shared code as nuget packages, and then you can use local feeds stored on a network drive or shared server to host your nuget packages. I just saw Teamcity 7 even has native support for hosting nuget feeds now.

The benefit of this is it's easy to share libraries without fixing locations (eg, it doesn't matter how a given developer or build server has their directories organized), and you can depend on specific versions as well as easily stay on the latest version.

Nuget packages can also do things beyond just provide simple DLL references: for example, it's possible to distribute javascript libraries or images or any other content. If you build several web apps that all share some same common setup (styles, forms, logins, whatever), you could package the required files/libraries/etc into a nuget package and then simply add the reference to the package.