Creating solutions to support multiple developers in Visual Studio

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

James Crosswell - 03 Oct 2007 18:32 GMT

I'm working with another developer on a solution that has a bunch of
different projects in it - we've got a central version control server
which I check stuff into and he checks stuff out of and vice versa.

Everything is fine so far. However some of these projects have external
dependencies on stuff like nUnit and nHibernate.

On my machine I've got all the files for our solution in a folder called
"X:\Foo\OurProject\" and I've got nHibernate installed in
"X:\Foo\nHibernate\" - I use nHibernate with other projects as well, so
I don't want to keep separate copies of this all over the palce... I
want to keep it there.

On the second developer's machine he's got his code stored in
"Y:\Bar\OurProject\" and he's got nHibernate installed in a directory
called "Y:\Bar\nHibernate\". Which creates a problem... most of the
files referenced in the project are files in the OurProject directory or
subdirectories of this, and thus can be referenced relative to the
OurProject.sln file. However references to NHibernate.dll are being hard
coded to:

X:\Foo\nHibernate\nhibernate\build\NHibernate-2.0.0.Alpha1\bin\net-2.0\NHibernate.dll

So when he syncs projects that I've checked into the version control
system he can't build them... he has to remove all the references to
NHibernate.dll and then add them back again (refering, of course, to the
hard coded path of these files on his machine - which in turn breaks the
project when I want to build it).

In short, what I'm after is some kind of equivallent of an environment
variable, only for Visual Studio 2005 projects/solutions. If I could
declare some kind of %HibernatePath% environment variable that I'd set
to "X:\Foo\nHibernate" on my machine and which he'd set to
"Y:\Bar\nHibernate" on his machine, and which we could use in the
references to these external dependencies then everything would be
fine... but I can't work out how to do this.

Can anyone give me a nudge in the right direction?

TIA.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

Reply to this Message

Tom Dacon - 03 Oct 2007 20:58 GMT

For files (not assembly references), map a network drive to a directory on
your local file system and store those files in that directory or a
subdirectory. In your projects, change the references to point there using
the mapped network drive. Have your other developer(s) map a network drive,
USING THE SAME DRIVE LETTER, to the directory in their local file system. If
there are subdirectories they must use the same directory structure as you
do.

For referenced assemblies, go into the registry on each machine and create
an assembly folders key that points to where they are in the local file
system. The base registry key for VS2005 is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx
Under that you create a key, named anything you like, and set its default
value to the directory path of wherever you keep the assemblies. VS2005 then
will look there as well as its other default locations for assembly
references for the projects. Each of you should do this.

HTH,
Tom Dacon
Dacon Software Consulting

> I'm working with another developer on a solution that has a bunch of
> different projects in it - we've got a central version control server
[quoted text clipped - 42 lines]
> Microforge.net LLC
> http://www.microforge.net

Reply to this Message

James Crosswell - 03 Oct 2007 23:18 GMT

Hi Tom,

Thanks for the reply.

> For files (not assembly references), map a network drive to a directory on
> your local file system and store those files in that directory or a
[quoted text clipped - 3 lines]
> there are subdirectories they must use the same directory structure as you
> do.

We're not actually on the same network (not even in the same continent),
but for the time being we don't have any need to reference external
files for any reason (just assemblies I think, so that he can have nUnit
and nHibernate installed in a different location to me).

> For referenced assemblies, go into the registry on each machine and create
> an assembly folders key that points to where they are in the local file
[quoted text clipped - 4 lines]
> will look there as well as its other default locations for assembly
> references for the projects. Each of you should do this.

Crikey! I'll certainly have to put that in a readme.txt file or
something in the root of the project directory! Not super intuitive is it?

By the way, does this sort of do the same thing as "Reference Paths" in
the project properties? "Reference Paths" looked like it would almost do
what I was after but it looked like I'd have to put my reference paths
in there, so would he, and that would just be a messy solution if you
ever had more developers working on the project (like 5 or 10
developers). Since there are loads of folks out there that regularly
work on projects with more than 5 or 10 developers I figured there must
be a more elegant/official way to do this...

I also noticed that "Referenced Paths" could be set at build time if you
were doing automated builds of the project... basically providing this
as a parameter to the build command. I wonder if it would be possible to
somehow make use of that from within Visual Studio, but I can't think of
a way presently.

In any case, thanks for the reply. The above "Registry Hack" will give
me SOME way of doing this until such a time as I can find some somewhat
less hacky team collaboration features of Visual Studio to do this. I
used to develop in Borland Delphi and it simply had IDE Environment
Variables that you set in the IDE to handle this problem, which was
really simple... And here was me thinking that team collaboration
features were supposed to be one of Visual Studio's strengths???

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

Reply to this Message

Tom Dacon - 04 Oct 2007 01:17 GMT

> Hi Tom,
>
[quoted text clipped - 12 lines]
> somehow make use of that from within Visual Studio, but I can't think of a
> way presently.

Right. "Reference Paths" ALMOST does what one needs, but unfortunately needs
to be set on a project-by-project basis, so it's not as convenient as the
machine-wide registry setting I described. I believe (but am not certain)
that it's not set directly in the vbproj file, but perhaps in the
vbproj.user file, which is local to the user and would not be checked in and
out of source control.

Because the registry setting works so well for my team, we don't use the
reference paths approach. We do however, use the mapped network drive
approach to let us get to our key file for signing during builds. We keep it
in the root of the source control tree, and so everyone gets a copy of it
but does not need to put the source tree in the same location on all
machines. The root directory of the source control tree is shared and
mapped, so the key file attribute in assemblyinfo looks something like (for
VB.Net):
<Assembly: AssemblyKeyFile("R:\BlahDeBlah.key")>

We all work distributed, too. We VPN in to our staging and production
environments when necessary but otherwise work completely disconnected. For
source control we use SourceGear Vault, which optionally connects using SSL
to our repository, so no VPN connection is necessary during development.

Tom Dacon
Dacon Software Consulting

Reply to this Message

Tom Dacon - 04 Oct 2007 01:21 GMT

A follow-up to my earlier response:

> Hi Tom,

> We're not actually on the same network (not even in the same continent),
> but for the time being we don't have any need to reference external files
> for any reason (just assemblies I think, so that he can have nUnit and
> nHibernate installed in a different location to me).

We're not on the same network either. What I meant by that was a directory
in the local file system, shared and then mapped to a drive letter using the
Tools/Map Network Drive dialog. It's completely local, but the location can
be referred to by the drive letter, and if all the devs use the same drive
letter then file references in the project files will resolve successfully
no matter who's machine it's on.

Tom

Reply to this Message

Creating solutions to support multiple developers in Visual Studio

Free Magazines