我在C ++工作;我是Visual Studio的新手，仍在努力了解如何有效地使用它。
我的问题是，我认为这是一个相当小的，非复杂的项目，但我发现自己在解决方案中添加了越来越多的项目，管理它们变得笨拙和令人沮丧。
DeviceInterface，并且我已FakeDevice和RealDevice实施该界面。Foo，我写的是一个静态库，使用DeviceInterface定义。 Foo库并不熟悉任何具体实现。TestExe1，TestExe2，等等。这些测试共享一些常用代码FooTestUtils。RealDevice需要在使用前后进行一些初始化和拆卸工作。这不属于在接口实现中的;客户端代码自然要对此负责。
RealDevice和init / teardown资源强烈依赖，则测试可执行文件只能使用RealDevice运行。使用假的我不需要或不想进行测试。FakeDevice，另一个用于执行初始化的RealDevice，然后调用相同的测试代码。TL; DR：核心库
Foo，具体取决于具有多个实现的DeviceInterface。多个测试可执行文件，其中大多数可以与DeviceInterface的任一实现一起使用，但其中一个实现需要在客户端代码中进行额外设置。
在我看来，这似乎是一个合理的复杂程度。但它导致SO MANY项目：
Foo RealDevice实施FooTestUtils（注意：包括FakeDevice实施）gtest（用于某些测试）RealDevice使用TestExe$i个项目在我不习惯的* nix环境中，我将代码划分为合理的目录树，以及很多这些＆＃34;项目＆＃34;它只是一个单独的目标文件，或者是一个带有核心逻辑客户端代码的单个.cpp。
对于此范围的解决方案，这是一个合理数量的项目吗？这对我来说感觉非常糟糕。经常我发现一些设置我需要改变六个不同的项目，我发现它越来越难以导航。目前，这仍然是可管理的，但我没有看到当我进入更大，更复杂的项目时，这将如何保持可行。 我可以更好地组织这个吗？
（同样，我是Visual Studio的新手，所以问题可能是我不知道如何管理多个相关项目，而不仅仅是项目本身的数量。）
答案 0 :(得分：4)
虽然你所做的事情非常标准 - 对于像你这样的小项目来说，解决方案似乎是完全标准的。 然而，Visual Studio确实提供了一些方法来最小化这些问题对经验丰富的开发人员的影响：
build-configurations和property-sheets：
简而言之，为什么有一个关于fakeDevice和RealDevice的项目？
为＆＃34; Device＆＃34;创建一个项目，根据所选择的配置构建fakeDevice或RealDevice的源代码。这也允许您在＆＃34;测试＆＃34;中开始您的项目。配置，并自动加载fakeDevice，同时选择＆＃34; Debug＆＃34;或＆＃34;发布＆＃34;将提供RealDevice。
请注意，两个项目以及整个解决方案可能独立配置 - 允许快速批量构建特定配置。
现实世界的例子
我的公司为adobe-illustrator制作了一个插件，有七个支持的Adobe版本（每个版本都带有它自己的SDK），以及32和64位版本，以及进一步的调试和发布版本（再次加倍到28） +变体，因为插件有两个几乎相同的品牌版本）。
我的解决方案如下：
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...}
在我的日常运作中，我很简单＆＃34;按播放＆＃34;在调试配置中，但是当发布时间到来时（或者特定版本需要测试）我会批量生成＆＃34;用于调试或打包的项目的正确组合。
这实际上意味着，虽然我有（包括共享库）近30个二进制文件正在为一个版本生成，但我的解决方案只有三个项目。
测试可执行文件
至于单元测试可执行文件，我建议为这些可执行文件创建一个单独的解决方案 - Visual Studio可以同时打开多个解决方案没有问题 - 但我有一个提示
创建一个单独的解决方案并在其中创建所有单元测试，然后在主解决方案中添加一个简单的＆＃34;测试＆＃34;项目，其中post-build event运行PowerShell /批处理脚本。
然后，该脚本可以在单元测试解决方案上调用MSVCC工具链，然后运行测试整理结果（如果您的配置正确）。 这将允许您从单个项目构建/运行测试，即使您确实需要alt + tab来创建新的单元测试。
个人（自以为是）建议
在Nix，Windows和Apple系统中开发，这是一个很好的布局方法。
＆＃39; Nix希望你创建自己的makefile和文件夹布局，它假设你确切知道你在做什么（在终端！）和布局成为你的玩物（有足够的shellcript）。
Windows / Visual Studio旨在向各级用户开放，在visual-basic上开展八年的学习计划，或者是经验丰富的C ++开发人员创建硬件驱动程序。因此，界面设计为非常可扩展 - ＆＃34;项目＆＃34; in＆＃34; solutions＆＃34;是一个基本的想法（很多初学者都没有意识到你可以有多个项目。但是如果你想要更多的选择，就MS而言，有一种方法（在这种情况下） ，配置和属性表） - 如果你编写一个makefile或创建一个布局，那么你做错了＃34;（无论如何都是在微软的眼中）。
如果你看一下过去几年中窗口生态系统中的麻烦增加，你会倾向于理解这个问题。在包含apt / yum作为依赖项的软件包中有几十个共享库的＆＃n; nix就好了！然而，Windows（感觉就像）拥有多个DLL是一个坏主意。没有包管理器，所以要么依赖.Net，要么用你的产品打包一个boost-dll。 （这就是为什么我更喜欢Windows上的静态链接。）
修改
如果您有多种配置，那么选择哪些来源并且不为每种来源构建，可以用两种方式完成。
一：手动
右键单击解决方案资源管理器中的任何源文件并选择属性 - 在＆＃34; general＆＃34;部分，您可以选择＆＃34;从构建中排除＆＃34; （如果您进行分组选择并右键单击，则此方法有效。
二：XML魔法
如果您打开vcxproj文件，那么您将完善格式良好的XML文件布局！
虽然处理包含，排除，甚至其他选项的确切条件超出了本文的范围，但可以找到基本的详细信息In this well worded stackoverflow question以及MDSN toolchain documentation