I am the intranet developer for the company I work for and I have been doing this for the last 5 years. My projects are divided into two solutions, the "Intranet" solution itself and the "Library" solution. The "Library" sln itself has several projects containing the DAL, BLL, etc.. The reason why I kept them in a different solution is because I thought that "maybe", one day my library sln can be used in other projects as well - you know reuse the code that I already wrote :) Well, that never happened. Now, since its so easier to have all projects in the same .sln, I am thinking to just do that. Is that a wise situation? What would you do if you were in my shoes?
A:
Yes, you can do it! You may still reuse your DAL and BLL, as the project settings are stored in the specific project files (csproj, vbproj, ...). Also dependencies are stored there, so no problem and good to go. I have an addin-infrastructure and for every and each addin-package, I do need the addin-host, which is included in several solution files. I never experienced any problems with this. Open up your *.sln file in a text-editor to see its contents...just links to the projects.
Scoregraphic
2009-10-02 12:38:58
A:
Simply add your library projects to your intranet sln. Keep your library solution as is.
loic
2009-10-02 12:39:31
A:
I would personally all add them to the same solution, yes. Namely, it doesn't matter if you plan on using some of the libraries in the solution in other projects: you can still add the compiled dll to those solutions, or you have the option to add them as an exisiting project to the new solutions.
So yes, I add everything to the same solution: gui-projects, libraries, even unit tests. Maybe if your solution becomes incredibly large (20+ projects, or larger) it would be better to split them up, but I've never worked on such large projects.
Razzie
2009-10-02 12:40:21
A:
I, for my part, have separated the Solutions and the projects, leaving me with a big punch of projects and only a few solution-files. I add all the projects I need in new solutions.
The upside is that I only have the projects in my workspace which I really need and it still changes in all other solutions. The downside is that it changes in all other solutions too, means that if you change the API of a widely used library, you'll have to check all your other solutions if incompatibilities.
Bobby
Bobby
2009-10-02 12:42:34
The incompatibilities normally come up with the next build. You may mark changed methods with the `Obsolete` attribute on changes in behaviour, so the compiler warns about them.
Scoregraphic
2009-10-02 12:50:28
Would you recommend to actually move the project files to the same folder where my intranet solution is located?
vikasde
2009-10-02 12:55:06
vikasde, I'd move all projects into one folder, and then separating them using solutions for each tool/program.
Bobby
2009-10-02 13:56:16
+2
A:
In the past I've used and reused the same 'project' in multiple solutions - I really just see a solution as a 'particular' instance of a collection of projects.
For example, we might have different solutions for the same overall piece of software depending on whether we want to be doing unit testing (in their own project) and or integration testing (in a separate project), and we'd open the right solution for what it is we're about to do. That way if you're doing normal coding with unit testing you don't have to build the integration test code every time and visa-versa.
Only thing to watch out for is bringing in a project to a solution that is a dependency of lots of other projects/solutions and then "accidentally" changing the code in it without realising it's in a side project rather than your main code. Then you can start breaking loads of other projects that depend on it and not realise!
Dave Amphlett
2009-10-02 12:47:14
Using continuous integration, like cruisecontrol.net will help a lot with realizing when you have changed a dependency.
dar
2009-10-02 12:53:01
This is very true - only problem here is whether you're continuously integrating apps that you've already released and aren't actively working on!
Dave Amphlett
2009-10-04 12:06:17
A:
I prefer to have 2 solutions. They both have identical structure (more or less) but the 2nd contains reusable infrastructure code only that isn't tied to a particular project. The thing is - your project code shouldn't contain framework-like (i.e. 'IsNumeric()' string extension method) stuff next to serious banking business logic (even if you won't reuse your 'Library'). That just makes things much more readable and maintainable.
For example:
Solution1:
- ProjectName.Core
- ProjectName.Infrastructure
- ProjectName.Application
- ProjectName.UI
- ProjectName.IntegrationTests
- ProjectName.UnitTests
And
Solution2:
- CompanyName.Core
- CompanyName.Infrastructure
- CompanyName.Application
- CompanyName.UI
- CompanyName.Tests
And I try not to have more than 10 projects in 1 solution. Otherwise - it leads to infinite toggling between "unload project"/"reload project.
Arnis L.
2009-10-02 12:56:49