views:

352

answers:

3

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?

+6  A: 
  • 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
Jon Skeet
I think some of these problems can be avoided if a virtual drive letter is created from a local folder using the subst command. Could you please elaborate on issue #1
SDX2000
When using a network folder this folder must also be added to the trusted locations using caspol afaik, so the setup of a new work environment is a little more complicated than simply opening and compiling a solution.
0xA3
@divo Can't this task be handled as part of a prebuild step?
SDX2000
Yes, that should be possible but it adds additional complexity and you will not have the same security configuration on your development system as on the target system. Of course this is not a must but it's not so attractive either...
0xA3
Issue 1 is about versioning of assemblies. Suppose I want to use a new version of NUnit (or whatever). That should just be updated in source control. Projects which rely on specific versions should branch/label the appropriate versions, and fetch those. Directories with version numbers doesn't scale
Jon Skeet
Ok got it. And I agree such assemblies should be maintained by the source control. But can you set relative paths to the assemblies in visual studio?
SDX2000
IIRC, if you browse to an assembly it will end up as a relative reference automatically.
Jon Skeet
Yup, you are right! I checked that. Thanks for the info, I did not know this since the path shown in the properties window is always the absolute path.
SDX2000
+1  A: 

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.

0xA3
+1  A: 

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.

SDX2000