我在C ++工作;我是Visual Studio的新手，仍然试图理解如何有效地使用它。
I'm working in C++; I'm new to Visual Studio and still trying to understand how to use it effectively.
我的问题是，我有一个相当小，非复杂项目，但我发现自己向解决方案添加了越来越多的项目，并且管理它们变得笨拙和令人沮丧。
My problem is that I have what seems to me a fairly small, non-complex project, but I find myself adding more and more Projects to the Solution, and managing them is becoming unwieldy and frustrating.
- 该项目取决于设备，因此我定义了 DeviceInterface 我有 FakeDevice 和 RealDevice 实现该界面。
- 项目 Foo ，我写了一个静态库，使用 DeviceInterface 定义。 Foo 库不熟悉任何具体的实现。
- 我有多个测试可执行文件，让我们称它们 TestExe1 ， TestExe2 等。这些测试共享一些常用代码 FooTestUtils 。
- 使用 RealDevice init和teardown工作前后使用。这不属于 接口实现;客户端代码自然负责这一点。
- 这意味着测试可执行文件只能使用 RealDevice 强依赖 RealDevice 和init / teardown资源。
- 我现在的解决方案是将测试可执行文件拆分为 FakeDevice ， RealDevice 另一个用于执行初始化，然后去调用相同的测试代码。
- The project depends on a device, so I've defined DeviceInterface, and I've got FakeDevice and RealDevice implementing the interface.
- My core project Foo, I've written is a static library, defined using DeviceInterface. The Foo library isn't familiar with either of the concrete implementations.
- I have multiple test executables, let's call them TestExe1, TestExe2, and so forth. These tests share some common code, FooTestUtils.
- Using RealDevice requires some init and teardown work before and after use. This doesn't belong within the interface implementation; the client code is naturally responsible for this.
- This means that a test-executable is only capable of running using RealDevice if I put in a strong dependency on RealDevice and the init/teardown resources. Which I don't need or want for tests using the Fake.
- My present solution is to split test executables up - one for FakeDevice, another for RealDevice that performs the initialization and then goes and calls the same test code.
TL; DR：核心库 Foo ，取决于 DeviceInterface ，它有多个实现。多个测试可执行文件，其中大多数可以使用 DeviceInterface 的实现，但其中一个实现需要在客户端代码中额外设置。
TL;DR: Core library Foo, depending on DeviceInterface, which has multiple implementations. Multiple test executables, most of which can work with either implementation of DeviceInterface, but one of those implementations requires extra set-up in the client code.
这在我看来似乎是一个合理的复杂程度。但它会导致SO MANY Projects：
This seems to me like a reasonable level of complexity. But it results in SO MANY Projects:
- 静态库：
- Foo
- RealDevice li> FooTestUtils （注：包括 FakeDevice 实施）
- gtest （用于某些测试）
- RealDevice 使用
- Static Libraries:
- Foo
- RealDevice implementation
- FooTestUtils (note: includes FakeDevice implementation)
- gtest (used for some of the testing)
- Library from another solution, needed for RealDevice use
- 2 TestExe $ i 每个测试可执行文件的项目
- 2 TestExe$i projects for every test executable I want
在* nix环境中，我更习惯，我将代码分成合理的目录树，很多这些项目只是一个单一的目标文件，或单个.cpp一些客户端代码的核心逻辑。
In the *nix environments I'm more used to, I'd divide the code into a reasonable directory tree, and a lot of these "Projects" would just be a single object file, or a single .cpp with some client code for the core logic.
这是一个合理的项目数量的解决方案这个范围吗？感觉像一个可怕的很多对我来说。通常我找到一些设置，我需要改变跨越六个不同的项目，我发现越来越难以导航。目前，这仍然是可管理的，但我不知道这将继续可行，因为我进入更大，更复杂的项目。 我可以组织更好吗？
Is this a reasonable number of projects for a solution of this scope? It feels like an awful lot to me. Frequently I find some setting I need to change across half a dozen different projects, and I'm finding it increasingly difficult to navigate. At present, this is still manageable, but I'm not seeing how this will remain workable as I proceed into larger, more complex projects. Could I be organizing this better?
（同样，我是Visual Studio的新手，所以问题可能是我不知道如何管理多个相关项目，而不仅仅是项目本身的数量。）
(Again, I'm new to Visual Studio, so the problem might be that I don't know how to manage multiple related projects, rather than just the number of the projects themselves.)
推荐答案标准 - 和一个像你这样的小项目描述你的解决方案似乎完全标准。 不过Visual studio确实提供了一些方法来最小化这些问题对有经验的开发人员的影响：
Though what your doing is pretty standard - and for a small project like you are describing you solution seems perfectly standard. However Visual studio does provide some ways to minimize the impact of these issues for experienced developers:
build-configurations 和属性表： 简而言之，为什么要为fakeDevice和RealDevice创建项目？
build-configurations and property-sheets: In short, why have a project for fakeDevice and RealDevice?
为Device创建一个项目，根据选择的配置，构建fakeDevice或RealDevice的源。这也允许您在测试配置中启动项目，并自动加载fakeDevice，同时选择调试或释放将提供RealDevice。
Create a project for "Device", that depending on what configuration is chosen builds the sources of fakeDevice, or those of RealDevice. This also allows you to start your project in "testing" configuration, and automatically load the fakeDevice, meanwhile selecting "Debug" or "release" would provide the RealDevice.
注
现实世界示例。 我的公司为adobe-illustrator生产一个插件，有七个支持的Adobe版本（每个都有自己的SDK），以及32和64位版本，进一步调试和发布版本（和双再次到28+变种，因为有两个近乎相同的品牌版本的插件）。 我的解决方案如下： 插件 - 解决方案 [Debug] [Release] /（win32 / x64）插件 [Debug AI4] [Debug AI5] [Debug AI6] [Debug AI7] [Release AI4] [Release AI5] [Release AI6] [Release AI7] /（win32 / x86）。 ..} 在我的日常操作中，我在调试配置中简单的按下播放，但是当发布时间到来（或特定的版本需要测试）
real world example My company produces a plugin for adobe-illustrator, there are seven supported versions of Adobe (each with it's own SDK), as well as 32 and 64bit variants, and further debug and release builds (and double that again to 28+ variants as there are two near-identical branded versions of the plugin). My Solution is as follows: Plugin-Solution [Debug][Release] / (win32/x64) Plugin [Debug AI4][Debug AI5][Debug AI6][Debug AI7][Release AI4] [Release AI5][Release AI6][Release AI7] / (win32/x86) {libraries with similar setups...} In my day to day operation, I simple "press play" in the debug config, however when release time comes (or a specific version needs testing) I "Batch Build" the correct combination of projects for debugging, or packaging.
这实际上意味着，虽然我有（包括共享库）接近足够的30个二进制文件被发布，我的解决方案只有三个项目。
This effectively means, although I have (including shared libraries) near-enough 30 binaries being produced for a release, my solution only had three projects within it.
测试可执行文件 对于单元测试可执行文件，我推荐为这些创建一个单独的解决方案 - Visual studio没有问题，有几个解决方案同时打开 - 我有一个提示
testing executables As for the unit-testing executables, I'd recommend creating a separate solution for those - Visual studio has no problem having several solutions open concurrently - I do however have one tip
创建一个单独的解决方案，并创建所有的单元测试在其中，然后在您的主要解决方案中添加一个简单的测试项目，在它的帖子-build event 运行powershell /批处理脚本。
Create a separate solution and create all your unit tests within it, then in your main solution add a simple "tests" project, in it's post-build event run a powershell/batch script.
然后，该脚本可以调用单元测试解决方案上的MSVCC工具链，然后运行测试整理结果（如果您在正确的配置）。 这将允许您从单个项目构建/运行测试，即使您需要使用alt + tab来创建新的单元测试。
That script can then invoke the MSVCC toolchain on the unit-tests solution, and then run the tests collating the results (if your in the correct configuration). This will allow you to build/run your tests from a single project, even if you do need to alt+tab to create a new unit test.
个人（建议）建议 开发了Nix，Windows和Apple系统，这里有一个很好的布局。 Nix希望你创建自己的makefile和文件夹布局，它假定你知道你在做什么（在终端！）和布局成为你的玩物（有足够的shellscripts）。 Windows / Visual studio旨在向每个级别的用户开放，一个在视觉基础上八年的学习程序，或者一个经验丰富的C ++开发人员创建硬件驱动程序。因此，界面被设计为非常可扩展的 - 项目在解决方案是一个基本的想法（许多初学者不意识到你可以有多个项目。但是如果你想要更多的选择，有一种方法（在这种情况下，配置和属性表） - 如果你编写一个makefile或创建一个布局你是做错了（在微软的眼睛）。
Personal (opinionated) Advice Having developed in 'Nix, Windows, and Apple systems, here's a good metaphore of layout. 'Nix expects you to create your own makefiles and folder layout, it assumes you know exactly what your doing (in the terminal!) and the layout becomes your plaything (with enough shellscripts). Windows/Visual studio is designed to be open to every level of user, an eight-yearold learning programs on visual-basic, or a experienced C++ developer creating hardware-drivers. As such the interface is designed to be very Expandable - "projects" in "solutions" is a basic idea (many beginners don't realise you can have multiple projects. However if you want more options, there is one way to do it as far as MS is concerned (in this case, configurations and property sheets) - if your writing a makefile or creating a layout you are "doing it wrong" (in microsoft's eyes anyway).
如果你看看在过去几年中适应Windows生态系统的麻烦，你会倾向于理解这个问题。在'nix有几十个共享 - 从一个软件包apt / yum安装作为依赖的库是好的！但是（感觉像是）有多个DLL是一个坏主意。没有包管理器，所以要么依赖.Net，或者打包一个单独的boost-dll与您的产品（这就是为什么我喜欢在Windows上的静态链接）。
If you take a look at the hassle boost has had fitting into the windows ecosystems over the last few years, you'll tend to understand the problem. On 'nix having several dozen shared-libraries from a package apt/yum installed as a dependency is fine! Windows however (feels like) having more than one DLL is a bad idea. There's no package-manager, so either rely on .Net, or package a single boost-dll with your product. (this is why I prefer static linking on windows).
编辑：
When you have multiple configurations, selecting what sources do and don't build for each can be done in two fashions.
一个：手动 b $ b右键单击解决方案资源管理器中的任何源文件并选择属性 - 在常规部分下，您可以选择从构建中排除（如果您选择组并右键单击，则可以使用。
one: manually Right clicking on any source-file in the solution explorer and selecting properties - Under the "general" section, you can select "Excluded From Build" (this works if you group-select and rightclick also.
two：XML magic 如果打开vcxproj文件，您将获得良好的XML文件布局！ 虽然处理管理包含的确切条件，排除，甚至其他选项超出了本文的范围，可以找到基本详细信息在这个良好的措辞stackoverflow问题以及 MDSN工具链文档
更多推荐
避免依赖项正在爆炸我的VS解决方案中的项目数量
发布评论