By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,395 Members | 2,524 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,395 IT Pros & Developers. It's quick & easy.

Project-->Project References Large Project

P: n/a
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

Jan 25 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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

Jan 25 '07 #2

P: n/a
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" <MNa...@gmail.comwrote 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
Jan 25 '07 #3

P: n/a
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
Jan 25 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.