Hi, I can add another reason to build a solution and not a projects: if you have projects for C# and C++ in one solution you can build only solution. Building projects one by one fails in this case.
Regards, Fyodor. On Fri, May 8, 2009 at 6:22 AM, Sam Calder <[email protected]> wrote: > I agree with Brendan. My point of view: > > Reasons to use project files and NOT use solution files: > > 1. A .sln file could be modified by a developer for, let's say, > > debugging purposes, and that could cause the build process to fail > > ...and any developer that checks that in & triggers the build needs to be > beaten about the head with a cluebat, same as anyone else who checks in any > other build-breaking change. Solution files generally don't actually contain > much more than GUIDS, project references and build configs (and if you are > unlucky enough to use SourceSafe, source control bindings). It's pretty hard > to screw up a solution file. > > 2. Solution files can use paths that do not work with the build > > process > > Not if they're referenced correctly (IE. relative paths), and your source > control is structured appropriately. > > 3. Using solution files goes against having small, more granular > > builds because this would require that a whole solution is retrieved > > from the repository > > Solution files give you a useful layer if indirection. Nothing's stopping > you having a solution file that contains one project, if you want. And if > you have an entire enterprise platform with 50+ project files in one > solution then yes you should consider breaking them up into separate > sensible solutions based on architectural purpose (data layer, common code, > web service, server, client, etc...), with binary dependencies. But you > don't have to break it up into 50+ separate build processes, nor do you have > to consolidate projects just to reduce the number of builds or build > complexity. > > 4. Automated unit tests cannot (or at least easily) be executed upon > each project build, but would rather have to be done after the whole > solution builds > > Per my response to #3, if your solutions are small and sensible it > shouldn't be that big a problem. In fact you may find you can reuse some of > the test setup/teardown test code, mocks, etc. too. > > Reasons to NOT use project files and instead use solution files: > > 1. Requires more work to setup the builds > > ...and it requires more work to maintain the existing builds too. You build > project-by-project, any time a new project is added, or renamed, or deleted, > you need to manually modify your build config. I use CCNET to build > solutions, you use it to build projects. I set up my CCNET build config a > year ago, it's maybe 30 lines long and it's hardly been modified since, > despite the fact my team has added maybe 20 projects to the solution file in > that time. Building from solution and having a sensible source-control > hierarchy makes it possible to incorporate changes automatically and > effortlessly. > > 2. using project files can require having to contend with false > > positives when a changeset covers many projects within the solution > > and a build cycle detects and starts building projects out of > > "order" (this can be resolved by always building a whole queue from > > the beginning, upon a detected change, of course). > > A good reason to use solution files, yes. See my response to #3... split > your entire enterprise solution to sensible layers & components, use good > interface-based design to split dependencies where appropriate, and you'll > find changesets of the type you propose don't actually happen very often - > and when they do, well you've already chained builds between your solution > files to accomodate it anyway... > > One additional benefit you neglected to mention - as a developer you open > and build the solution file. If your build process opens and builds the same > file you can easily guarantee what the developer builds is what the build > process will build. This reliability is extra important if you rely on your > build process to create releases. > > My $0.02. I'd recommend using solution files whenever possible, and only > dropping back to projects if absolutely necessary. > > Cheers, > > - Sam. > > > > On Thu, May 7, 2009 at 8:10 PM, Brendan Crosser-McGay > <[email protected]>wrote: > >> Rebuttal to Reasons to use project files and NOT use solution files: >> 1. Solution files maintain internal consistency of environments across all >> projects connected together. Make as many environments that you need when >> you start the project and the solution file allows you to switch >> environments across all projects, and make sure that they are all in sync. >> That's why each project should at least have two environments, Debug and >> Release. Developers who check in changes that break the build is actually a >> useful metric, and can encourage a team to run their unit tests before >> checking in so they don't break the build. Besides, sometimes a broken >> build on a solution can reveal weaknesses that need attention. >> >> 2. You are going to have larger issues if you have static paths in your >> solution file. Visual Studio automatically uses dynamic paths in your >> project so it doesn't matter where the solution file and project files are >> as their base, as they can be loaded just about anywhere. The solution file >> should be seen as a "grouping" of files together under a single umbrella to >> achieve a common goal. There isn't an easy way (in visual studio) to >> signify that a certain set of files are essential to the entire set of >> projects besides using solution level folders and files. >> >> 3. If you have special needs, make lots of solution files, you can use the >> same projects in as many solutions as you like. >> >> 4. The act of an entire solution either passing or failing by means of it >> building is usually a very important metric. Unit tests are typically >> contained in a separate project, and thus you would have an uphill battle >> trying to get useful test results if you were building and testing all >> projects independently. Interdependence testing across projects would be >> sacrificed if it's possible to test one project based on outdated versions >> of another project. >> >> Rebuttal to Reasons to NOT use project files and instead use solution >> files: >> 1. Creating a solution in Visual Studio, and then adding specific projects >> you need for the build to function is trivial, and can be done in less then >> a minute or two (depending on how fast your PC is.), all visual studio >> slowness aside. :) I know I have a number of projects in my source control >> that are used in multiple solutions with much success. >> >> 2. Visual studio manages this, and resolves dependencies. >> >> No disrespects meant, but have you been using Visual Studio for long, or >> are you coming over to it from another IDE or language entirely? Developing >> in Visual Studio would be quite difficult without using the "solution" >> system built into it, especially when developing a number of different >> interdependent projects. The best example I've found so far is >> CruiseControl.NET's source code itself, as it's built in C# and uses a >> solution file with a number of dependent files included. >> >> Cheers, >> Brendan >> >> >> On Thu, May 7, 2009 at 4:56 PM, ogaz <[email protected]> wrote: >> >>> >>> I am hoping some of you can offer some thoughts on this-- >>> >>> I am trying to list reasons to use Visual Studio project files instead >>> of Visual Studio solution files to build projects (e.g. CCNet --> >>> MSBuild task --> .csproj instead of CCNet --> MSBuild task -- >>> > .sln). I am of the thinking that ideally it is **generally** best >>> to build using project files instead solution files. >>> >>> Reasons to use project files and NOT use solution files: >>> 1. A .sln file could be modified by a developer for, let's say, >>> debugging purposes, and that could cause the build process to fail >>> 2. Solution files can use paths that do not work with the build >>> process >>> 3. Using solution files goes against having small, more granular >>> builds because this would require that a whole solution is retrieved >>> from the repository >>> 4. Automated unit tests cannot (or at least easily) be executed upon >>> each project build, but would rather have to be done after the whole >>> solution builds >>> >>> Reasons to NOT use project files and instead use solution files: >>> 1. Requires more work to setup the builds >>> 2. using project files can require having to contend with false >>> positives when a changeset covers many projects within the solution >>> and a build cycle detects and starts building projects out of >>> "order" (this can be resolved by always building a whole queue from >>> the beginning, upon a detected change, of course). >>> >>> >>> >> >
