References and multi developer projects

[Claire]

Visual studio .net 2003.

We have created 2 solutions that are related to and dependent on each
other's class libraries. One of them is executed as required, the other one
sits in the task bar. I'm working on the task bar application and my
colleagues are developing the other.
All of us need to do work on a single class library/project that is included
in both solutions.
When the solutions are finished they're both located in the same directory.

This class library, to this moment, has been written by me. It references
some other class libraries (database interface stuff from my collleagues'
solution) which I've grouped in a sub directory for convenience. I create
references to those dlls by selecting "Add reference" then browsing to the
sub folder and selecting the dlls.

The problem is that now my colleague needs to edit my class library. He's
added my project to his solution and the compilation failed because his
project directory structure is different to mine and those DLLs are not in
the same place as on my machine.

We can't use the global library cache, the dlls and applications have to be
located in the same directory as each other for certain reasons.

The only answer we could think of was for me to add the other solutions
class libraries to mine as projects and compile my own version of their dlls
so that the references were project based rather than directory based.
This seems a very poor solution to our problem.

Can anyone come up with a cleaner answer please?

Claire

 

[Claire]

I've fixed it. I added the new directory to the references path in project
properties.

thanks anyway

 

[Guest]

And use Visual SourceSafe. It's integrated into VS and doesn't require you to
do anything once you've got it set up.

 

[Guest]

For each class library, have a test bench, a project whose *only* purpose is
to test that class library, and to make sure it operates as required. That
can include any complexities that an actual application may face, but it's
just a test bench - and it has a project reference to the library it is to
test. Then, when you want to actually *use* the class library in a project,
you only ever need set a reference to the compiled binary. If it generates an
error, you reproduce the behaviour that caused the error in the test bench,
and debug it until the class library can handle it. Then you do a release
build, which will be picked up the next time you build your client project.
That's what I do anyway.

 

[Jon Skeet [C# MVP]]

And use Visual SourceSafe. It's integrated into VS and doesn't require you to
do anything once you've got it set up.

And it'll lose your code for you if you're unlucky. Not to mention that
it assumes you're on a LAN, using file sharing for everything, which
leads to terrible performance over a VPN.

Seriously, I'd strongly advise against VSS. It's a horrible, horrible
source control system. I'm really hoping that the team system in the
enterprise edition of VS.NET 2005 does things properly...

See http://www.michaelbolton.net/testing/VSSDefects.html for more
reasons against using VSS.