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). >> >> >> >
