避免依赖关系使我的 VS 解决方案中的项目数量激增
Avoiding dependencies is exploding the number of projects in my VS solution
我正在使用 C++；我是 Visual Studio 的新手，仍在努力了解如何有效地使用它。
我的问题是我有一个在我看来相当小、不复杂的项目，但我发现自己向解决方案中添加了越来越多的项目，并且管理它们变得笨拙且令人沮丧。
- 该项目依赖于一个设备，所以我定义了
DeviceInterface，并且我已经 FakeDevice 和 RealDevice 实现了接口。
- 我的核心项目
Foo，我写的是一个静态库，使用DeviceInterface定义。 Foo 库不熟悉这两个具体实现。
- 我有多个测试可执行文件，我们称它们为
TestExe1、TestExe2，等等。这些测试共享一些通用代码，FooTestUtils.
- 使用
RealDevice 需要在使用前后进行一些初始化和拆卸工作。这不属于 within 接口实现；客户端代码自然对此负责。
- 这意味着如果我强烈依赖
RealDevice 和 init/teardown 资源，则测试可执行文件只能 运行 使用 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.
在我看来，这似乎是一个合理的复杂程度。但它导致了很多项目：
- 静态库：
FooRealDevice实施FooTestUtils（注意：包括 FakeDevice 实施）gtest（用于部分测试）- 来自另一个解决方案的库，需要
RealDevice 使用
- 可执行文件：
- 2
TestExe$i 个项目用于我想要的每个测试可执行文件
在我更习惯的 *nix 环境中，我会将代码划分到一个合理的目录树中，其中很多 "Projects" 只是一个目标文件，或者单个.cpp 和一些核心逻辑的客户端代码。
这个范围的解决方案的项目数量合理吗？我觉得太多了。我经常发现我需要在六个不同的项目中更改一些设置，而且我发现它越来越难以导航。目前，这仍然是可管理的，但我看不出随着我进入更大、更复杂的项目，这将如何保持可行。 我可以更好地组织这个吗？
（同样，我是 Visual Studio 的新手，所以问题可能是我不知道如何管理多个相关项目，而不仅仅是项目本身的数量。）
尽管您所做的是非常标准的 - 对于像您描述的这样的小项目，您的解决方案似乎非常标准。
然而，Visual studio 确实提供了一些方法来为有经验的开发人员最大限度地减少这些问题的影响：
build-configurations and property-sheets:
总之，为什么要有fakeDevice和RealDevice的项目？
为 "Device" 创建一个项目，根据选择的配置构建 fakeDevice 或 RealDevice 的源。这也允许您在 "testing" 配置中启动项目，并自动加载 fakeDevice，同时 selecting "Debug" 或 "release" 将提供 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...}
在我的日常操作中，我在调试配置中简单 "press play"，但是当发布时间到来时（或特定版本需要测试）我 "Batch Build" 调试或打包项目的正确组合。
这实际上意味着，尽管我（包括共享库）为一个版本生成了将近 30 个二进制文件，但我的解决方案中只有三个项目。
测试可执行文件
至于单元测试可执行文件，我建议为它们创建一个单独的解决方案 - Visual studio 同时打开多个解决方案没有问题 - 但是我有一个提示
创建一个单独的解决方案并在其中创建所有单元测试，然后在您的主解决方案中添加一个简单的 "tests" 项目，其中 post-build event 运行 a powershell/batch 脚本。
然后该脚本可以在单元测试解决方案上调用 MSVCC 工具链，然后 运行 测试整理结果（如果您的配置正确） .
这将允许您 build/run 从单个项目进行测试，即使您确实需要 alt+tab 来创建新的单元测试。
个人（自以为是）建议
在 'Nix、Windows 和 Apple 系统中开发，这里有一个很好的布局比喻。
'Nix 希望您创建自己的 makefile 和文件夹布局，它假定您确切地知道自己在做什么（在终端中！）并且布局成为您的玩物（有足够的 shellscripts）。
Windows/Visual studio 旨在向各个级别的用户开放，无论是八岁学习 visual-basic 程序的儿童，还是创建硬件驱动程序的经验丰富的 C++ 开发人员。因此，界面设计得非常可扩展 - "solutions" 中的 "projects" 是一个基本想法（许多初学者没有意识到你可以有多个项目。但是如果你想要更多选项，有 一种方法 就 MS 而言（在这种情况下，配置和 属性 工作表）- 如果您编写 makefile 或创建布局，您是 "doing it wrong" （无论如何在微软眼中）。
如果您看一下过去几年 windows 生态系统所带来的麻烦提升，您就会倾向于理解这个问题。在 'nix 上，将软件包 apt/yum 中的几十个共享库作为依赖项安装就可以了！ Windows 但是（感觉）拥有多个 DLL 是一个坏主意。没有包管理器，因此要么依赖 .Net，要么将单个 boost-dll 与您的产品打包在一起。 （这就是为什么我更喜欢 windows 上的静态链接）。
编辑：
当您有多个配置时，select可以通过两种方式确定每个源做什么和不做什么。
一个：手动
右键单击解决方案资源管理器中的任何源文件并 selecting 属性 - 在 "general" 部分下，您可以 select "Excluded From Build" （如果您分组 -select 并右击。
二：XML魔法
如果你打开 vcxproj 文件，你会得到一个格式正确的 XML 文件布局！
虽然处理管理包含、排除甚至其他选项的确切条件超出了本 post 的范围，但可以找到基本详细信息 In this well worded Whosebug question as well as the MDSN toolchain documentation
我正在使用 C++；我是 Visual Studio 的新手，仍在努力了解如何有效地使用它。
我的问题是我有一个在我看来相当小、不复杂的项目，但我发现自己向解决方案中添加了越来越多的项目，并且管理它们变得笨拙且令人沮丧。
- 该项目依赖于一个设备，所以我定义了
DeviceInterface，并且我已经FakeDevice和RealDevice实现了接口。 - 我的核心项目
Foo，我写的是一个静态库，使用DeviceInterface定义。Foo库不熟悉这两个具体实现。 - 我有多个测试可执行文件，我们称它们为
TestExe1、TestExe2，等等。这些测试共享一些通用代码，FooTestUtils. - 使用
RealDevice需要在使用前后进行一些初始化和拆卸工作。这不属于 within 接口实现；客户端代码自然对此负责。- 这意味着如果我强烈依赖
RealDevice和 init/teardown 资源，则测试可执行文件只能 运行 使用RealDevice。我不需要或不想使用 Fake 进行测试。 - 我目前的解决方案是将测试可执行文件拆分 - 一个用于
FakeDevice，另一个用于执行初始化然后调用相同测试代码的RealDevice。
- 这意味着如果我强烈依赖
TL;DR: Core library
Foo, depending onDeviceInterface, which has multiple implementations. Multiple test executables, most of which can work with either implementation ofDeviceInterface, but one of those implementations requires extra set-up in the client code.
在我看来，这似乎是一个合理的复杂程度。但它导致了很多项目：
- 静态库：
FooRealDevice实施FooTestUtils（注意：包括FakeDevice实施）gtest（用于部分测试）- 来自另一个解决方案的库，需要
RealDevice使用
- 可执行文件：
- 2
TestExe$i个项目用于我想要的每个测试可执行文件
- 2
在我更习惯的 *nix 环境中，我会将代码划分到一个合理的目录树中，其中很多 "Projects" 只是一个目标文件，或者单个.cpp 和一些核心逻辑的客户端代码。
这个范围的解决方案的项目数量合理吗？我觉得太多了。我经常发现我需要在六个不同的项目中更改一些设置，而且我发现它越来越难以导航。目前，这仍然是可管理的，但我看不出随着我进入更大、更复杂的项目，这将如何保持可行。 我可以更好地组织这个吗？
（同样，我是 Visual Studio 的新手，所以问题可能是我不知道如何管理多个相关项目，而不仅仅是项目本身的数量。）
尽管您所做的是非常标准的 - 对于像您描述的这样的小项目，您的解决方案似乎非常标准。 然而，Visual studio 确实提供了一些方法来为有经验的开发人员最大限度地减少这些问题的影响：
build-configurations and property-sheets:
总之，为什么要有fakeDevice和RealDevice的项目？
为 "Device" 创建一个项目，根据选择的配置构建 fakeDevice 或 RealDevice 的源。这也允许您在 "testing" 配置中启动项目，并自动加载 fakeDevice，同时 selecting "Debug" 或 "release" 将提供 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...}
在我的日常操作中，我在调试配置中简单 "press play"，但是当发布时间到来时（或特定版本需要测试）我 "Batch Build" 调试或打包项目的正确组合。
这实际上意味着，尽管我（包括共享库）为一个版本生成了将近 30 个二进制文件，但我的解决方案中只有三个项目。
测试可执行文件
至于单元测试可执行文件，我建议为它们创建一个单独的解决方案 - Visual studio 同时打开多个解决方案没有问题 - 但是我有一个提示
创建一个单独的解决方案并在其中创建所有单元测试，然后在您的主解决方案中添加一个简单的 "tests" 项目，其中 post-build event 运行 a powershell/batch 脚本。
然后该脚本可以在单元测试解决方案上调用 MSVCC 工具链，然后 运行 测试整理结果（如果您的配置正确） . 这将允许您 build/run 从单个项目进行测试，即使您确实需要 alt+tab 来创建新的单元测试。
个人（自以为是）建议
在 'Nix、Windows 和 Apple 系统中开发，这里有一个很好的布局比喻。
'Nix 希望您创建自己的 makefile 和文件夹布局，它假定您确切地知道自己在做什么（在终端中！）并且布局成为您的玩物（有足够的 shellscripts）。
Windows/Visual studio 旨在向各个级别的用户开放，无论是八岁学习 visual-basic 程序的儿童，还是创建硬件驱动程序的经验丰富的 C++ 开发人员。因此，界面设计得非常可扩展 - "solutions" 中的 "projects" 是一个基本想法（许多初学者没有意识到你可以有多个项目。但是如果你想要更多选项，有 一种方法 就 MS 而言（在这种情况下，配置和 属性 工作表）- 如果您编写 makefile 或创建布局，您是 "doing it wrong" （无论如何在微软眼中）。
如果您看一下过去几年 windows 生态系统所带来的麻烦提升，您就会倾向于理解这个问题。在 'nix 上，将软件包 apt/yum 中的几十个共享库作为依赖项安装就可以了！ Windows 但是（感觉）拥有多个 DLL 是一个坏主意。没有包管理器，因此要么依赖 .Net，要么将单个 boost-dll 与您的产品打包在一起。 （这就是为什么我更喜欢 windows 上的静态链接）。
编辑：
当您有多个配置时，select可以通过两种方式确定每个源做什么和不做什么。
一个：手动
右键单击解决方案资源管理器中的任何源文件并 selecting 属性 - 在 "general" 部分下，您可以 select "Excluded From Build" （如果您分组 -select 并右击。
二：XML魔法
如果你打开 vcxproj 文件，你会得到一个格式正确的 XML 文件布局！
虽然处理管理包含、排除甚至其他选项的确切条件超出了本 post 的范围，但可以找到基本详细信息 In this well worded Whosebug question as well as the MDSN toolchain documentation