What are the principles of organizing C++ code in Visual Studio?

Question

I'm a seasoned C++ developer in a new position. My experience is in *nix-based systems, and I'm working with Visual Studio for my first time.

I find that I'm constantly struggling with Visual Studio for things I consider trivial. I feel like I haven't grokked how I'm supposed to be using VS; so I try doing things "the way I'm used to," which takes me down a rabbit-hole of awkward workarounds, wasted time, and constant frustration. I don't need a VS 101 tutorial; what I need is some kind of conversion guide - "Here's the VS way of doing things."

That's my general question - "What's the VS way of doing things?". That might be a bit vague, so I'll describe what's giving me grief. Ideally, I'm not looking for "Here's the specific set of steps to do that specific thing," but rather "You're looking at it wrong; here's the terms and concepts you need to understand to use VS effectively."

---

In C++, I'm used to having a great measure of control over code organization and the build process. I feel like VS is working strongly against me here:

• I strongly tend to write small, isolated building blocks, and then bigger chunks that put those blocks together in different combination.
  • As a trivial example, for a given unit or project, I make a point of having strong separation between the unit's headers meant for client inclusion; the unit's actual implementation; and any testing code.
  • I'm likely to have multiple different test projects, some of which will probably rely on common testing code (beyond the code-under-test itself).
• VS makes it onerous to actually control code location. If I want a project's code to be divided into an include/ folder and a src/ folder, that's now a serious hassle.
• VS's concept of "projects" seems, as far as I can tell, somewhere between what I'd think of as "final build target" and "intermediate build target." As far as I can tell, basically anything I want to share between multiple projects, must also be a project.
  • But if many intermediate objects now become projects, then I'm suddenly finding myself with a TON of small projects.
  • And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.
  • This encourages me to lump lots of unrelated code together in a single project, just to reduce the number of projects I need to manage.

---

I'm struggling with this constantly. I can find solutions to any one given thing, but it's clear to me that I'm missing a wider understanding of how Visual Studio, as a tool, is meant to be used. Call it correct workflow, or correct project organization - any solutions or advice would be a real help to me.

(Note: much as I'd like to, "Stop working with the Visual Studio buildchain" is not an option at the moment.)

Answer 1

The basic rule is: A project results in a single output file [1].

If you want to package building blocks into static libraries, create a project for each one.

Unit test are separate from the code, so it's common to see a "foo" and a "foo test" project side by side.

With respect to your small building blocks, I use this guideline: If it is closely enough related to be put in the same folder, it is closely enough related to be put in the same project.

And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.

Property pages are intended to solve this problem. Just define a property page containing related settings and definitions, and it becomes as easy as adding the property page to a new project.

As each project can pull its settings from multiple property pages, you can group them into logical groups. As an example: a "unit test" property page with all settings related to your unit test framework.

To create property page in Visual Studio 2015: in the View menu, there is an option "Property Manager". You get a different tree view of your solution, with the projects, then the configurations, and then all the property pages for that project+configuration combination. The context menu for the configuration has an option to create a new property page or to add an existing one.

---

[1] Although it is common to have the Release configuration result in foo.dll and Debug configuration in food.dll, so they can exist next to each other without resorting to the Debug/ and Release/ folders. In the General properties, set the TargetName to "$(ProjectName)d" (for Debug configuration) and remove the "$(Configuration)" from the OutputDirectory (for all configurations) to achieve this.