Project assembly references between team members

Question

I was curiious to know what type of structures you use for your project references?

Where I work the developers have a shared folder called AssemblyCache (\\MACHINENAME\AssemblyCache) which is mapped to an R:\ via GPO in Windows 2008 AD (tied to the Developers AD group).

Our shared components have post-build events that copy them to something like this:

R:\.Net %VERSION%\Project\%SOMETHING%

Sometimes it's followed by either 'Common' if it's common to the project or something specific. There's also a common directory for shared stuff under the .Net version folder.

This is so large projects over multiple solutions can reference the assemblies from a common place.

The build machine also has a shared drive of the same share name which the developers have mapped to S:. This allows them to get the latest working build should they need it.

All this is so someone can get on a new PC, and open a project without having to copy references to varying locations, and ensuring that dev a is referencing the assembly from the same place as dev b etc...

This solution works well for us, so I was wondering what, if any, solutions you have in-place for ensuring all developers reference assemblies from the same path?

Answer 1

You dont need to create a network share. I think you can get away with creating a virtual drive letter for a local folder using the windows subst command for example...

subst R: "C:\.Net %VERSION%\Project\%SOMETHING%"

The advantage here is that an arbitrary path can be routed to a standard well defined path for assemblies hence for example different assembly versions can be remapped to the fixed reference path used by visual studio.

Answer 2

• Store all the reference assemblies in source control.
• Always fetch such that the code has the same relative path to the assemblies (e.g. ../../CommonLibraries)
• Everyone fetches to a local drive

Having to refer to a network drive causes various issues:

• No way of branching for a later version, referring to earlier versions for existing branches
• Difficulties working offline
• Build machine etc depends on the other machine - it's not a self-contained build
• Performance isn't great

Answer 3

In one project we added assemblies to the source code repository. This is also not perfect, but it prevents from accidentally getting a newer version of a reference which could happen easily when using a file share.