When you start a brand new project, Visual Studio creates a solution.
Whenever I need to add extra functionality, I create a subfolder under the project and keep coding.
In other words, I have Solution A and Project 1 only.
However, I feel like I’m missing something (e.g. code management and compiling) by doing this instead of creating a new project under the same solution.
In other words, Solution A, Project 1, Project 2, Project 3 etc.
So, what are the deciding factors, or when do you use a new project under an existing solution instead of just creating subfolders in Project 1 of Solution A?
Dependency is easy; if the project produces a .DLL, or is a web service, for example, and you need to invoke it from another project then there is a dependency.
For small projects (like one screen and a few database calls) everything is likely to be in a single project. As they get larger, or as you need to reuse a .DLL for example on multiple projects, then you need to have better organization. The solution,
project organization scheme helps you to manage it. If you don't need it you don' t have to use it.
The project in question is a Web Site project, (not web app) and it does not produce a single DLL.
I checked the precompiled /bin folder and there's over 750 dll and application extensions.
To take your example of a web service as a situation for creating a project; I have so far just created a subfolder and created the ASMX for it.
Yes, the web site started out small many moons ago, but now there's over 110 root folders, and countless subfolders.
Whenerver I build the single project it takes a while not to mention uploading the whole thing - over 10 minutes.
So, I guess projects allow me to micro manage compilation and upload smaller chunks??
I am unsure where to break the single project into multiple projects.
If there are some best practice or guideline docs, that would be hepful. Thanks.
PS. The concept of code reuse is great, but in my various "real-world projects" it seems there is always something different that requires modifications thus prohibiting pure module reuse.
I suppose the answer to "when?" is a bit subjective in some ways.
However, there is no rule that will satisfy all cases; experience, judgement, wisdom. All of those come from doing it and deciding that it can be improved.
My normal rule however is the same as for classes or a method. Make them as small as possible. I would rather have e.g. 10 small projects in a solution, each of which was dedicated to a single pattern or function or subsystem or service, rather than one
huge project that has too much messy dependencies.. That way each one can be upgraded, tested, replaced independetly of the others.
Dedicate a project to one part of the system. A UML diagram can help to make these decisions. Architcture and experience all help. Study other large systems and see how they broke out the data tier from the logic tier and so on.
Thanks! /m.
Marked as answer by Keep it Simple on Dec 05, 2012 08:08 PM
My normal rule however is the same as for classes or a method. Make them as small as possible. I would rather have e.g. 10 small projects in a solution, each of which was dedicated to a single pattern or function or subsystem or service, rather than one huge
project that has too much messy dependencies.. That way each one can be upgraded, tested, replaced independetly of the others.
Bad idea. You're introducing a lot of friction for benefits that are nothing more than cosmetic.
First, splitting a solution into a large number of small projects significantly increases compilation times.
Second, it has no benefit whatsoever for dependency management, only problems. You don't reduce the overall number of dependencies, you just end up expressing them in multiple places -- a violation of DRY which will bite you hard when you need to change
them or to add a new build configuration to your solution.
Third, you shouldn't be upgrading components independently of each other. It means you end up with a version of your code going into production that hasn't been integration tested properly, and doesn't correspond to a single, definitive revision in source
control. Set up a continuous integration server instead and get a decent branching and tagging strategy in place.
The key to remember is that assemblies (projects) are a unit of deployment, not a unit of
organisation. The general rule is to have as few projects in your solution as you can get away with. If you need to separate your layers out, that's what namespaces are for.
Keep it Simp...
Member
549 Points
264 Posts
When do you add new project?
Dec 04, 2012 07:49 PM|LINK
When you start a brand new project, Visual Studio creates a solution.
Whenever I need to add extra functionality, I create a subfolder under the project and keep coding.
In other words, I have Solution A and Project 1 only.
However, I feel like I’m missing something (e.g. code management and compiling) by doing this instead of creating a new project under the same solution.
In other words, Solution A, Project 1, Project 2, Project 3 etc.
So, what are the deciding factors, or when do you use a new project under an existing solution instead of just creating subfolders in Project 1 of Solution A?
madflatpicke...
Member
301 Points
67 Posts
Re: When do you add new project?
Dec 04, 2012 08:07 PM|LINK
re: deciding factors;
the solution file (.sln) isn't that big; you create multiple projects within the same solution when they have some dependency on each other.
Something like: the data management project, the user interface project , the special logic project, all for the same overall system or subsystem.
Otherwise, creating a new solution is good as you won't introduce cross compilation dependencies and other weirdness.
Keep it Simp...
Member
549 Points
264 Posts
Re: When do you add new project?
Dec 04, 2012 08:35 PM|LINK
That's the part that is unclear. How do you clearly determine dependency?
For data management, I have datasets in a DAL folder in App_Code.
For User Interface, an ASPX page is an ASPX page, right?
For special Logic, I use C# class files in a BLL folder in App_Code.
I truly want to see a better way with multiple projects, but it seems it adds unecessary complexity???
By the way, I'm not asking about multiple solutions.
madflatpicke...
Member
301 Points
67 Posts
Re: When do you add new project?
Dec 04, 2012 09:33 PM|LINK
Dependency is easy; if the project produces a .DLL, or is a web service, for example, and you need to invoke it from another project then there is a dependency.
For small projects (like one screen and a few database calls) everything is likely to be in a single project. As they get larger, or as you need to reuse a .DLL for example on multiple projects, then you need to have better organization. The solution, project organization scheme helps you to manage it. If you don't need it you don' t have to use it.
Keep it Simp...
Member
549 Points
264 Posts
Re: When do you add new project?
Dec 05, 2012 12:17 AM|LINK
The project in question is a Web Site project, (not web app) and it does not produce a single DLL.
I checked the precompiled /bin folder and there's over 750 dll and application extensions.
To take your example of a web service as a situation for creating a project; I have so far just created a subfolder and created the ASMX for it.
Yes, the web site started out small many moons ago, but now there's over 110 root folders, and countless subfolders.
Whenerver I build the single project it takes a while not to mention uploading the whole thing - over 10 minutes.
So, I guess projects allow me to micro manage compilation and upload smaller chunks??
I am unsure where to break the single project into multiple projects.
If there are some best practice or guideline docs, that would be hepful. Thanks.
PS. The concept of code reuse is great, but in my various "real-world projects" it seems there is always something different that requires modifications thus prohibiting pure module reuse.
madflatpicke...
Member
301 Points
67 Posts
Re: When do you add new project?
Dec 05, 2012 02:02 PM|LINK
I suppose the answer to "when?" is a bit subjective in some ways.
However, there is no rule that will satisfy all cases; experience, judgement, wisdom. All of those come from doing it and deciding that it can be improved.
My normal rule however is the same as for classes or a method. Make them as small as possible. I would rather have e.g. 10 small projects in a solution, each of which was dedicated to a single pattern or function or subsystem or service, rather than one huge project that has too much messy dependencies.. That way each one can be upgraded, tested, replaced independetly of the others.
Dedicate a project to one part of the system. A UML diagram can help to make these decisions. Architcture and experience all help. Study other large systems and see how they broke out the data tier from the logic tier and so on.
jammycakes
Participant
1315 Points
274 Posts
Re: When do you add new project?
Dec 08, 2012 12:23 PM|LINK
Bad idea. You're introducing a lot of friction for benefits that are nothing more than cosmetic.
First, splitting a solution into a large number of small projects significantly increases compilation times.
Second, it has no benefit whatsoever for dependency management, only problems. You don't reduce the overall number of dependencies, you just end up expressing them in multiple places -- a violation of DRY which will bite you hard when you need to change them or to add a new build configuration to your solution.
Third, you shouldn't be upgrading components independently of each other. It means you end up with a version of your code going into production that hasn't been integration tested properly, and doesn't correspond to a single, definitive revision in source control. Set up a continuous integration server instead and get a decent branching and tagging strategy in place.
The key to remember is that assemblies (projects) are a unit of deployment, not a unit of organisation. The general rule is to have as few projects in your solution as you can get away with. If you need to separate your layers out, that's what namespaces are for.