Links to build projects between team members

Question

I was interested to know what structures you use for your projects?

In cases where I work, developers have a shared folder named AssemblyCache (\\ MACHINENAME \ AssemblyCache), which is mapped to R: \ objects through a GPO in Windows 2008 AD (linked to the Developers developer group).

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

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

Sometimes this was accompanied either by the “General”, if it was common to the project, or by something specific. There is also a shared directory for shared files in the version folder. Net.

These are so large projects over several solutions that can reference assemblies from a common place.

The collector also has a shared drive with the same name that the developers associated with S :. This allows them to get the latest build if they need it.

All this means that someone can get to the new computer and open the project without copying the links in different places, and make sure that dev a refers to the assembly from the same place as dev b, etc ...

This solution works well for us, so I was wondering what solutions you have to ensure that all developers refer to assemblies from the same path?

Answer 1

You do not 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 substitution command, for example ...

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

The advantage is that an arbitrary path can be redirected to a standard well-defined path for assemblies, therefore, for example, different versions of an assembly can be reassigned to a fixed reference path used by visual studio.

Answer 2

• Store all reference assemblies in the source control.
• Always choose so that the code has the same relative assembly path (e.g. .. / .. / CommonLibraries).
• Everyone chooses a local drive

When accessing a network drive, various problems arise:

• No branching method for later version, referring to earlier versions for existing branches
• Difficulties working offline
• Assembly machine, etc. depends on another machine - this is not an independent assembly
• Low performance

Answer 3

In one project, we added assemblies to the source code repository. It is also not ideal, but it prevents accidentally getting a newer version of the link, which can happen easily when using file sharing.