Where to place the .dlls?

Where to place the .dlls?

Old forum URL: forums.lhotka.net/forums/t/5231.aspx


MadGerbil posted on Tuesday, August 12, 2008

I'm starting a new project and reading through C# Business Objects 2005.

Building the project and including a reference to the CSLA .dlls is no problem; however, I want to include those compiled .dlls in my project in such a way that they are saved to SourceSafe.  Typically, I just drop copies of them into my bin folder, include them in the project, establish references to them and move on.

I'm wondering if that is the correct way to do it though.

Is there a more "correct" way to include these CSLA dlls as a part of my project?

The goals here are:

1: I don't want a full copy of the CSLA framework included in my project as a part of the solution.  I only need the compiled DLLS.

2: For the sake of disaster recovery it is important that a user be able to install a copy of VS2005 and open the project from SourceSafe and immediately be able to be up and running.  I don't want them to worry about having a folder stashed somewhere, or something in the GAC, or any of that nonsense.

 

So, if you include the compiled DLLS in your project where should they be?  How should they be handled?

DancesWithBamboo replied on Tuesday, August 12, 2008

Each of my projects has a "Reference" folder where I put all of my third-party components.  Then it is checked into TFS with the rest of the code.  So I think we use the same technique.

Fintanv replied on Tuesday, August 12, 2008

I follow the practice of having a \lib sub-directory as part of the directory structure of my solution.  In this sub-dir I have other directories that hold specific dlls such as the MS Ent Lib, the Infragistics controls, Nunit, Nant, Typemock, Csla, etc.  All of these get incorporated into the svn repository so that my solution has all of the dependencies used to build it.  This is of use when two years down the road you need to make a change to the application, and dont have to try to figure out where to get the old versions of the dlls.  Since I work on validated systems these is not a minor issue. 

When I make a reference to these dlls I do so to the lib path version.  It is my understanding that if you have copies of the dll's in the GAC, then these are used first even if you reference the dll in a different location.  This is only a problem if the dlls have the same assembly version, but different file versions, as then you are building your solution with the wrong dll.

Some may balk at the thought of storing all these extra bits in the repository, but experience has shown me that the pros outweigh the cons.  Svn also does binary diffs so changes to the dlls are not painful in terms of wasteful space.  I do not think vss does binary diffs (not sure of this though), so am not sure of the ramifications in your particular case.

Hope this helps,

Fintan

MadGerbil replied on Tuesday, August 12, 2008

My only thought is that putting these files in the 'bin' directory may be a bit confusing since the difference between what the application put in the bin and what the programmer put there might blur.

I like the idea of a distinct folder.

jeff replied on Tuesday, August 12, 2008

Definitely exclude bin/obj folders from source control. Here's what I do for each "application":

trunk - solution file goes here
trunk/build - build scripts. Also I point all my projects to a bin directory here instead of their own.
trunk/lib - 3rd party components to be distributed with the app (csla, ui libraries, etc)
trunk/src - contains a folder per .net project
trunk/tools - 3rd party components not distributed (mbunit, mocking stuff, etc.)

"trunk" would just be your project root. I'm following subversion recommended trunk/tags/branches folders to work on multiple versions of the same source.


Copyright (c) Marimer LLC