Actually Bob, I found a better article on this:
http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/en-us/dnbda/html/tdlg_ch3.asp
In my case, we have 7 or so shared projects that
several of our applications use. The thing is, as
these shared components evolve, we don't want
The big benefit to the project references is that you
can step into the code. Log4net, we definitely
wouldn't want to do that with, but it can be helpful
for these in house projects...
--- Rod Ayers [EMAIL PROTECTED] wrote:
A great, helpful discussion
I absolutely agree with the concept
I think that would be REALLY tough to maintain here.
In one of our apps, we have around 30 projects with
many dependancies interwoven throughout. The easiest
thing for me, I think, is to use the solution task
like this:
target name=build
solution configuration=release
projects
It's not as bad as it may sound. The system I developed
this for had around 220 assemblies in it in a mixture of C# and VB.NET,
but maintenance of the scripts was never a problem.
Cheers,
Bill
From Eric Fetzer [EMAIL PROTECTED]@lists.sourceforge.net
Sent by: [EMAIL PROTECTED]
Eric Fetzer wrote:
The big benefit to the project references is that you
can step into the code. Log4net, we definitely
wouldn't want to do that with, but it can be helpful
for these in house projects...
You can step into the project even without project references - if the
debug symbols
