Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Guidance on solution and project structure.

Guidance on solution and project structure.

Scheduled Pinned Locked Moved Design and Architecture
questionlearning
7 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B Offline
    B Offline
    Brady Kelly
    wrote on last edited by
    #1

    I now have to deal with a whole lot of very badly structured solutions and projects. My first bugbear is solution files within project folders. To me this smells very bad, as projects are subordinate to solutions, and maintaining a healthy solution folder structure should not rely only on the solution file contents, but should be implicit in the actual Windows folder structure. I would like to propose a standard for use by me and my colleagues, and in this suggest a truly hierarchical structure with a Code folder containing a solution file, and subordinate folders for all projects, containing only .csproj files and source, no solution files! I would very much also like to include some useful background information justifying my proposal, but I don't want to ramble too much and would like sources I could maybe quote, with attribution of course. What good articles, tutorials, books, etc. could I consult for this?

    L R B 3 Replies Last reply
    0
    • B Brady Kelly

      I now have to deal with a whole lot of very badly structured solutions and projects. My first bugbear is solution files within project folders. To me this smells very bad, as projects are subordinate to solutions, and maintaining a healthy solution folder structure should not rely only on the solution file contents, but should be implicit in the actual Windows folder structure. I would like to propose a standard for use by me and my colleagues, and in this suggest a truly hierarchical structure with a Code folder containing a solution file, and subordinate folders for all projects, containing only .csproj files and source, no solution files! I would very much also like to include some useful background information justifying my proposal, but I don't want to ramble too much and would like sources I could maybe quote, with attribution of course. What good articles, tutorials, books, etc. could I consult for this?

      L Offline
      L Offline
      Luc Pattyn
      wrote on last edited by
      #2

      let's see[^]... :)

      Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

      Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.

      B R 2 Replies Last reply
      0
      • L Luc Pattyn

        let's see[^]... :)

        Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

        Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.

        B Offline
        B Offline
        Brady Kelly
        wrote on last edited by
        #3

        I'm sure most questions here could be answered by Google. In fact, most of mine are actually answered by Google, but I like forums because they introduce experience factors versus mere PageRank. :)

        L 1 Reply Last reply
        0
        • B Brady Kelly

          I'm sure most questions here could be answered by Google. In fact, most of mine are actually answered by Google, but I like forums because they introduce experience factors versus mere PageRank. :)

          L Offline
          L Offline
          Luc Pattyn
          wrote on last edited by
          #4

          The first few hits seemed quite to the point, and your post did show interest but not really prior research, hence... :)

          Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

          Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.

          1 Reply Last reply
          0
          • L Luc Pattyn

            let's see[^]... :)

            Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

            Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.

            R Offline
            R Offline
            RobCroll
            wrote on last edited by
            #5

            lol, hate the cynicism, love the approach.

            1 Reply Last reply
            0
            • B Brady Kelly

              I now have to deal with a whole lot of very badly structured solutions and projects. My first bugbear is solution files within project folders. To me this smells very bad, as projects are subordinate to solutions, and maintaining a healthy solution folder structure should not rely only on the solution file contents, but should be implicit in the actual Windows folder structure. I would like to propose a standard for use by me and my colleagues, and in this suggest a truly hierarchical structure with a Code folder containing a solution file, and subordinate folders for all projects, containing only .csproj files and source, no solution files! I would very much also like to include some useful background information justifying my proposal, but I don't want to ramble too much and would like sources I could maybe quote, with attribution of course. What good articles, tutorials, books, etc. could I consult for this?

              R Offline
              R Offline
              RobCroll
              wrote on last edited by
              #6

              I don't see the problem with having individual solutions Thats a good thing, particularly if the solution can be implemented in isolation. Also I can't see a problem with other more enterprise type solutions being able to reference projects within another solutions. I doubt you will find a book or article expressly on the subject because it is a fundamental principle of OOP. I think what maybe more concerning is a lack of namespacing guidance. As enterprises develop over time, namespacing does become an issue (that's life) and changing namespacing is relatively simple. What you need to consider in backward compatibility. Changing namespacing can cause upgrade deployment issues.

              1 Reply Last reply
              0
              • B Brady Kelly

                I now have to deal with a whole lot of very badly structured solutions and projects. My first bugbear is solution files within project folders. To me this smells very bad, as projects are subordinate to solutions, and maintaining a healthy solution folder structure should not rely only on the solution file contents, but should be implicit in the actual Windows folder structure. I would like to propose a standard for use by me and my colleagues, and in this suggest a truly hierarchical structure with a Code folder containing a solution file, and subordinate folders for all projects, containing only .csproj files and source, no solution files! I would very much also like to include some useful background information justifying my proposal, but I don't want to ramble too much and would like sources I could maybe quote, with attribution of course. What good articles, tutorials, books, etc. could I consult for this?

                B Offline
                B Offline
                Bernhard Hiller
                wrote on last edited by
                #7

                I disagree with your ideas. We have a few solutions, and some of them share projects, e.g. both Solution1 and Solution2 make use of ProjectA. And here, the structure you suppose would fail. Our sln files reside in the "main" project of a solution, not in a shared project. When shared projects contained sln files, I would not like that either.

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups