Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Solution folders

So what’s your collective take on solution folders with Visual Studio?

For the longest time, I didn’t pay them no never mind. Then there was a brief period when I had an intense love affair with them. Everything went into my solution. Third-party libraries, testing tools, documentation, damning evidence that other members of the team were plotting to beat me up and steal my lunch money. At my last contract, even the projects were organized within solution folders and when I first saw that, I nodded approvingly to myself.

The rationale was that if it was in the solution, I didn’t need to leave Visual Studio to deal with source control. It was safe in Visual Studio. It gave me comfort. Even joy. Windows Explorer was a scary place and this TortoiseSVN/Explorer integration wackiness was just plain FREAKY FRIDAY! Better to stay in my happy place.

Then I noticed cracks in the veneer. I couldn’t add a physical folder to a solution folder and have it magically add all the files within it to my solution. I felt a slight twinge of annoyance at having to navigate an extra layer to get to the project I wanted. And at the risk of being called a "slave to my tools" (which is a funny accusation at the best of times, unless the accusers writes code in Notepad and compiles from the command line with csc), I do enjoy the Collapse All Projects feature of Gaston Milano’s CoolCommands, which didn’t work as nicely with that extra layer.

So now I find myself back to having all my projects at the top level and using solution folders sparingly for things like batch files, build files, and readme files. I ventured out of my comfort zone in Visual Studio and learned to deal with third party library folders and tool folders externally. And really, it only took one time re-creating the full NAnt folder structure in solution folder format to make me drop the practice.

How about you? What do you store in solution folders? Do you maintain a project hierarchy in them? Use them for any non-code-type files? Love them long time or hate them with a Charles Bronson-like vengeance?

Kyle the Solvable

This entry was posted in Coding Style. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.merill.net Merill

    Having figured out that the solution folders were a little flaky, I opted to create empty projects to replace the solution folders and then removed them from the default build. This way I get to include all sub folders etc within my solutions.

  • http://www.indomitablehef.com Chris Hefley

    I use them for build files and any .template files (config.template, sql.template) that get tokenized by Nant during the build. I find I use it most for editing web.config.template, and the .build file(s)

  • http://colinjack.blogspot.com/ Colin Jack

    We originally used them a lot in our domain model solution but in the end we broke off a lot of sub-soltuons instead.

    However we still have one overall solution and in there we have a few solution folders, for example we have “CRM” containing all our CRM projects and within that solution folder we have another “Test” solution folder with all the CRM test projects.

    Actually one nice thing about solution folders is you can hide them, which I use a lot.

  • Andrew

    We use seperate solutions for seperate concerns and lots of assembly linking if required.

    So, we try to cut down on how many projects we have in a single solution and make sure our solutions for a project take a proper directory structure from our root drive.

    We then mirror the same structure on the build server, so when we do a check in, it gets the same assembly linkages on the build server (and if we’ve configured the build correctly in the same build order/triggers/etc), so we don’t have any issues with that.

    And as well try to make each atomic element of our systems reusable across many projects (working in-house for a firm makes this easier than in a consulting role, I bet :).

    So basically we house the projects directly in the solution, and use the solution folder for any critical notes, and basically little things like FxCop – anything that may change and need to be checked in to source control (ie if our assembly changes or we add a project and we need to redo the FxCop, it gets updated in source control for the build server to pick up).

  • Anonymous

    We use solution folders for assembly version and signature files and create links to them within each project. That way we only have to update one file when changing the version number.

  • Mark

    We use solution folders for projects that are not in the specific layer that the solution is focused at. If it is the application, then projects from lower layers in the stack will be found in solution folders, sometimes multiple folders one per layer.

  • http://jimmybogard.lostechies.com Jimmy Bogard

    I like to use solution folders for existing legacy projects because they tend to be huge and have existing nonsensical organization. One solution has 50 projects, 3 web apps, 5 services, etc. and I need solution folders to make sense of the madness. These are projects where project name != root namespace name != assembly name and each folder might have 10 different namespaces.

    On green- or brown-field projects, I use a single “solution items” folder that holds my common config files (StructureMap.config, Log4Net.config, hibernate.cfg.xml), my build file, and any other common or non-code files. I find with good naming and structuring conventions, folders aren’t necessary.