Project-->Project References Large Project

D

DonJefe

Does anyone have experience using project->project references in large
solutions? What are the plus/minuses that you have found?

Currently, we are using the binary assembly references for our code,
but this becomes problematic when you want to build from multiple
branches/working directories.

Any thoughts on this would be appreciated.

Thanks
 
D

Dave Sexton

Hi,

I recommend using project references over assembly references. Personally,
I like having all of the projects in one solution as long as it doesn't
hamper development (too much clicking and searching can get annoying).

It may seem a bit strange having all of my required utility libraries added
to every solution that uses them as projects, but I do that also. I like to
be able to update the utility libraries when I find bugs or to add new
features while I'm using them.

Another benefit of project references is that it helps to be able to quickly
debug all of the projects from within the same solution by using breakpoints
and being able to step into other projects. Although this is possible
without project references, you'd have to reference the assembly with the
debug symbols, which brings me to my last point...

Project references also allow you to build a debug or release configuration
by just changing the solution configuration. With assembly references you'd
have to do some rewiring first for release builds.

An alternative for team development is to use smaller solutions that contain
only the projects that a particular team requires, with assembly references
to the other projects, and then create one major solution that builds the
final release with project references to all. The build solution would tie
in all of the teams components and could be used for a nightly debug build
and the ultimate release build.

The only problem that I've seen with project references (if you want to call
it a problem) is that source control complains about the binding root being
different from the solution for each of the utility projects.

Another advantage, regarding dependency and build order, can be found on
MSDN:

Project References
§ Project-to-Project References and File References
http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx
 
D

DonJefe

Sounds logical. How about build time? Some of our guys think that will
greatly increase the build time and the rebuild time when you have a
"build broken, fix one project, rebuild" scenario.
 
L

Laurent Bugnion [MVP]

Hi,
Sounds logical. How about build time? Some of our guys think that will
greatly increase the build time and the rebuild time when you have a
"build broken, fix one project, rebuild" scenario.

The build is differential, so once a referenced project is built, it is
not built again, unless you change something in the project itself or in
one of the projects this one references. Additionally, managed build is
much faster than unmanaged build, so it's not really an issue. We have a
fairly big application, and we run hourly builds without problems.

There are huge advantages using project references over assembly
references. The version problems can give huge headaches...

Dave's proposal to use smaller solutions for invidual development works
great too.

HTH,
Laurent
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top