c++ - 避免依赖关系使我的VS解决方案中的项目数量激增

Question

我在用C++工作；我是Visual Studio的新手，仍在尝试了解如何有效地使用它。

我的问题是，我有一个很小的，不复杂的项目，但是我发现自己向解决方案中添加了越来越多的项目，并且对其进行管理变得笨拙而令人沮丧。

该项目取决于设备，因此我已经定义了DeviceInterface，并且已经实现了实现该接口(interface)的FakeDevice和RealDevice。

我写的核心项目Foo是一个静态库，使用DeviceInterface定义。 Foo库对这两种具体实现都不熟悉。

我有多个测试可执行文件，我们称它们为TestExe1，TestExe2等。这些测试共享一些通用代码FooTestUtils。

使用RealDevice需要在使用前后进行一些初始化和拆卸工作。这不属于接口(interface)实现；客户代码自然要对此负责。

这意味着，如果我强烈依赖RealDevice和init / teardown资源，那么test-executable仅能够使用RealDevice运行。我不需要或不想使用Fake进行测试。

我目前的解决方案是将测试可执行文件拆分为一个可执行文件，一个用于FakeDevice，另一个用于RealDevice，执行初始化，然后调用相同的测试代码。

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.

在我看来，这似乎是一个合理的复杂程度。但这导致了许多项目:

静态库:

Foo

RealDevice实现

FooTestUtils(注意:包括FakeDevice实现)

gtest(用于某些测试)

来自另一个解决方案的库，RealDevice需要使用

可执行文件:

每个想要的测试可执行文件2个TestExe$i项目

在我比较习惯的* nix环境中，我将代码划分为合理的目录树，其中许多“项目”将只是一个目标文件，或者是一个带有某些客户端代码的.cpp文件。核心逻辑。

这是该范围内解决方案的合理数量的项目吗？ 对我来说感觉真是太糟糕了。通常，我发现需要在六个不同的项目中进行更改的设置，而且导航变得越来越困难。目前，这仍然是可管理的，但是在继续进行更大，更复杂的项目时，我看不出它如何仍然可行。 我可以组织得更好吗？

(再次，我是Visual Studio的新手，所以问题可能是我不知道如何管理多个相关项目，而不仅仅是项目本身的数量。)

Answer 1

尽管您的工作非常标准-对于像您这样描述的小型项目，解决方案似乎是完全标准的。
但是，Visual Studio确实提供了一些方法来最大限度地减少这些问题对有经验的开发人员的影响:

build-configurations和property-sheets:
简而言之，为什么有一个针对fakeDevice和RealDevice的项目？

为“设备”创建一个项目，该项目根据选择的配置来构建fakeDevice或RealDevice的源。这还允许您以“测试”配置启动项目，并自动加载fakeDevice，同时选择“Debug”或“release”将提供RealDevice。

请注意，两个项目以及整个解决方案都可能具有独立的配置-允许快速批量构建特定的配置。

真实世界示例
我公司为adobe-illustrator制作了一个插件，有7个受支持的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...}在日常操作中，我会在调试配置中简单地“按播放”，但是当发布时间到来(或特定版本需要测试)时，我会“批量构建”正确的项目组合以进行调试或打包。

这实际上意味着，尽管我(包括共享库)为发行版生产了将近30个二进制文件，但我的解决方案中只有三个项目。

测试可执行文件
至于单元测试的可执行文件，我建议为它们创建一个单独的解决方案-Visual Studio并发打开多个解决方案没有问题-但是我有一个提示

创建一个单独的解决方案并在其中创建所有单元测试，然后在主解决方案中添加一个简单的“tests”项目，在post-build event中运行powershell / batch脚本。

然后，该脚本可以在单元测试解决方案上调用MSVCC工具链，然后运行测试以对结果进行整理(如果您的配置正确)。
即使您确实需要alt + tab创建新的单元测试，这也允许您从单个项目构建/运行测试。

个人(建议)咨询
在'Nix，Windows和Apple系统中进行了开发之后，这里是布局的一个很好的比喻。
'Nix希望您创建自己的makefile和文件夹布局，它假设您确切地知道自己在做什么(在终端中!)，并且布局成为您的玩物(具有足够的shellscript)。
Windows / Visual Studio旨在向所有级别的用户开放，基于Visual Basic的已有八年历史的学习程序，或者是经验丰富的C++开发人员创建硬件驱动程序。因此，该界面被设计为非常可扩展的-“解决方案”中的“项目”是一个基本概念(许多初学者并没有意识到您可以拥有多个项目。但是，如果您想要更多的选择，可以通过一种方法来实现)就MS而言(在这种情况下，是配置和属性表)-如果您编写Makefile或创建布局，则“做错了”(无论如何在Microsoft看来)。

如果您看一下过去几年来Windows的生态系统已经遇到了麻烦，那么您会倾向于理解这个问题。在'nix上，从apt / yum软件包中安装了数十个共享库作为依赖项就可以了!但是，Windows(感觉像)具有多个DLL是一个坏主意。没有包管理器，因此要么依赖.Net，要么将单个boost-dll与产品打包在一起。 (这就是为什么我更喜欢Windows上的静态链接)。

编辑:
当您有多个配置时，可以通过两种方式选择为每个源构建和不构建的源。

一:手动
右键单击解决方案资源管理器中的任何源文件，然后选择属性-在“常规”部分下，可以选择“从构建中排除”(如果您同时进行组选择和右键单击，则可以使用。

二:XML魔术
如果打开vcxproj文件，则将优化格式良好的XML文件布局!
尽管处理管理包含，排除和其他选项的确切条件超出了本文的范围，但基本详细信息可以在In this well worded stackoverflow question和MDSN toolchain documentation中找到