views:

74

answers:

1

Hello, I am trying to set up my Visual Studio projects. I have a generic project (say SharedProj) that has all the constants, common classes. SharedProj will be referenced by two other solutions (say SolnA, SolnB), but potential more in the future.

There are two ways I can think of:

  • I can add SharedProj to both SolnA and SolnB.
  • Or I can add the SharedProj.dll to the References in both SolnA and SolnB.

Since this is my first time working on a solution that references other projects/solutions, is one way preferred than the other?

By the way, is there any easy way to rename a variable name in SharedProj and updates all references to this variable? Like if I rename a variable's name within the project, there's an option that says "Rename 'old' to 'new'" which renames everything.

Thanks for your help.

+1  A: 

The way I handle this is to create a solution for just the common code project. Build the library, then publish it in a common location. You might want to name or otherwise keep different versions of the same library distinct in this location. Then I include a reference to the published libraries in any solutions/projects that need them. Since I often share these and my solutions with other developers, I tend to keep them on a network share and reference them using UNC paths to avoid naming issues with respect to drive letters when sharing my code.

Using versioning in your libraries allows you the ability to upgrade dependent projects on your timeline rather than forcing you to upgrade all whenever a change is made or having to maintain your code in several places. Note that the more people you have using the common code the more important that this is.

tvanfosson
Thanks, using UNC paths sounds like a good solution. That also solves another potential problem which is that I need to tell other developers to download SharedProj and build it (maybe update the reference in SolnA) before he/she can compile SolnA.
David