Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Third Party Libraries Organization

I finally have my CI environment and am wondering what the heck took me so long to take time to get it set up. This has had me looking again at how I set my project folders up. Typically I am using the libraries from Castle/Nhib/Rhino stack and build them all at the same time quite frequently since the Rhino build process simply ROCKS. However I notice everyone putting all their dependencies in separate folders like this:

  • /lib/Castle
  • /lib/NHibernate
  • /lib/Rhino
  • /lib/...

Personally, I have just thrown all my dependencies in a single /lib folder and haven't come across issues with this. I still keep tools like mbunit or nant in a separate /tools directory.

My /lib directory isn't as pretty organized looking but like I said most of my dependencies are getting rebuilt at the same time anyways. So what advantage am I missing out on by just throwing everything into a single folder? It has made it much simpler for copying assemblies from other builds (I know I could automate that too).  Am I being overly simplistic?


Posted 05-09-2008 9:46 PM by Michael Nichols

[Advertisement]

Comments

Jak Charlton wrote re: Third Party Libraries Organization
on 05-10-2008 1:09 AM

I just do it becasue it makes it easy to get to the one I am after when I do add reference :)  Plus I sometimes have the source + tooling there too (so for example the whole NUnit GUI and Console runner ... ) and there are hundreds of files

Derik Whittaker wrote re: Third Party Libraries Organization
on 05-10-2008 8:01 AM

I just have to ask, why are u rebuilding your libraries?  

Are you making changes to Rhino/Windsor, etc.  If you are NOT then rebuilding them just seems like a waste of cycles.

Mike wrote re: Third Party Libraries Organization
on 05-10-2008 11:25 PM

I usually do have some features I am working on inside one of the sources, yes. Until recently there were some pretty invasive features I had in my local copy that wasn't patched in.

Plus, features I find interesting are frequently being added to one of the projects so I like to keep up with it. I have found it simpler to keep up with the changes rather than try to figure out all that has happened later on and really with all the work Ayende and company have put into the build process has made it so simple there isn't a reason not to.

Derick Bailey wrote re: Third Party Libraries Organization
on 05-13-2008 11:13 AM

if lib/ is your assembly location that projects reference, then I don' t see any problem doing this. i typically put all of my pre-compiled assemblies in a single folder like this, as well.

if you're talking about the source of these tools, then i think there's obvious reasons you want them each in their own sub-folder... it's easier to see what's what and not get confused with a bunch of different solutions in one folder.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)