Per my previous post, I figured I would outline how we do things at work from an organizational point of view.
We name all of our projects using the .net framework design and naming guidelines...
RootNamespace.ProjectNamespace.ApplicationNamespace
Just like most of Microsoft's namespaces start with Microsoft or System all of our assemblies and projects begin with the same name: 'CodeMakerX'
We decided on this name rather than a company name, because at the time we started our .net initiative we were in the process of being bought by a much larger company. We refer to this as our root or company namespace. The project namespace is pretty simple to decipher, it contains everything pertaining to a particular project. The application namespace delineates between different applications in a particular project. I use the term project loosely here since it doesn't necessarily pertain to one vs.net project file, but more often to a set of project files. Some examples are listed below.
I have changed the names of our projects to protect the innocent...
CodeMakerX.Foundation
Conceptual
Our foundation assembly is referenced from every single .net application we have ever written. We use a project reference in every solution. Mainly for ease of deployment/development. We tried using the GAC at the very beginning and found it too tedious to work with. I will admit it might have been a failure to understand the ramifications and abilities of the GAC, but it caused a alot of pain regardless.
Physical
CodeMakerX.Foundation.dll
/Repository
/CodeMakerX
/Foundation
/Data
/EntityFramework
/Utility
CodeMakerX.Foundation.csproj
Logical
CodeMakerX.Foundation
This is the core of all projects using .net. Everything starts here. We have our own BaseException class that custom exceptions inherit from as well as our resource classes for exception messages.
CodeMakerX.Foundation.Data
This contains a modified version of the Data Access Block, we redid some of it as well as making it custom to support multiple connection strings.
CodeMakerX.Foundation.EntityFramework
This contains all of our base functionality for our data abstraction objects.
CodeMakerX.Foundation.Utility
This contains all of our string/math/security/comparison utility methods.
CodeMakerX.SomethingMakerX
Conceptual
This project is usually based on data model. This assembly contains the unique business code as well as a data abstraction layer that provides a mapping of classes to tables in our database.
Physical
CodeMakerX.SomethingMakerX.dll
/Repository
/SomethingMakerX
/SomethingMakerX
/Business
/DataAbstraction
CodeMakerX.SomethingMakerX.csproj
Logical
CodeMakerX.SomethingMakerX.Business
This contains the code specific to business rules and operations.
CodeMakerX.SomethingMakerX.DataAbstraction
This contains the mapping classes for our database tables to classes, our Manager classes for crud functionality and strongly typed collection objects.
CodeMakerX.SomethingMakerX.AdminWeb
Conceptual
This project contains the web files for managing the SomethingMakerX application.
Physical
CodeMakerX.SomethingMakerX.AdminWeb.dll
/Repository
/SomethingMakerX
/AdminWeb
/Lib/ThirdParty/Assemblies
CodeMakerX.SomethingMakerX.AdminWeb.csproj
Logical
The namespaces in this project don't usually go beyond this, we put html interfaces, usercontrols, and aspx pages here. We create lib folder for third party controls if needed and they aren't shared across multiple projects.
Usually I create a CodeMakerX.WebMakerX.Sln file, then I put CodeMakerX.Foundation, CodeMakerX.WebMakerX, CodeMakerX.WebMakerX.AdminWeb projects into that solution. Then I wire up the project references between all of these projects. I don't commit any /bin folders to the source control repository. We have been working in this same fashion for over 1.5 years and we don't have any of the problems mentioned in Chris' or Fabrice's posts about problems. Am I missing something?
I saw Chris'
post and Fabrice's
post and I guess I am just confused. I don't use VSS (We use Subversion) and I don't use the source control stuff inside of vs.net. Maybe that is where I am making a disconnect.
Where I work we used Web Projects at first, but then decided to move to a local project model. Using local projects works better in case you have different working folder configurations (some developers here prefer XP and use virtual directories, some of us use Windows 2003 with different websites and use port numbers to seperate our applications). With web projects we were tied to that .webinfo file. We finally wisened up and stopped checking that file in along with the product's solution file (this contains url specific information also when using web projects).
By moving to local projects we have negated all of this bad behavior. I guess I feel exactly opposite from Chris and Fabrice, I am glad they didn't require us to use web projects.
The problems that I am hearing Chris and Fabrice complain about are preventable (I know because we went through the same issues), as far as I know, you aren't REQUIRED to check in the bin folder. It is actually a bad idea to do so. The bin is really a dynamic folder, everytime you compile it changes. Also your source control can't revision .dll or binary files, so why bother? It is just taking up space in your source control repository.
Your source control repository is for storing code and resources for the project. Since the bin folder is a dynamic resource that is only a compile away, stop putting it in source control.
Hope this helps