Project-->Project References Large Project

[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

[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/lib...ew(VS.80).aspx

--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"DonJefe" <MN****@gmail.comwrote in message
news:11**********************@v33g2000cwv.googlegr oups.com...

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

[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.
On Jan 25, 12:22 pm, "Dave Sexton" <dave@jwa[remove.this]online.com>
wrote:

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 liketo
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 Referenceshttp://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx

--
Dave Sextonhttp://davesexton.com/bloghttp://www.codeplex.com/DocProject(Sandcastle in VS IDE)

"DonJefe" <[e-mail] in messagenews:11**********************@v33g2000cwv.g ooglegroups.com...

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

[Laurent Bugnion [MVP]]

Hi,

DonJefe wrote:

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
--
Laurent Bugnion [MVP ASP.NET]
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch