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?
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
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.
Copyright (c) Marimer LLC