代码之家 › 专栏 › 技术社区 › Ziv

避免依赖性使我的VS解决方案中的项目数量激增

code-organization visual-studio c++

2

Ziv · 技术社区 · 8 年前

我在C++中工作;我对VisualStudio是新手,仍在尝试了解如何有效地使用它。

我的问题是,我有一个在我看来相当小、不复杂的项目,但我发现自己在解决方案中添加了越来越多的项目,管理它们变得笨拙和令人沮丧。

项目依赖于设备,所以我定义了 DeviceInterface ,我有 FakeDevice 和 RealDevice 实现接口。
我的核心项目 Foo ,我写的是一个静态库,使用 设备接口 这个 Foo公司 库不熟悉这两种具体实现。
我有多个测试可执行文件,让我们调用它们 TestExe1 , TestExe2 等等这些测试共享一些通用代码, FooTestUtils .
使用 RealDevice(真实设备) 需要在使用前后进行一些初始化和拆卸工作。这不属于 在内部 接口实现;客户端代码自然对此负责。
- 这意味着测试可执行文件只能使用 RealDevice(真实设备) 如果我对 RealDevice(真实设备) 以及初始化/拆卸资源。我不需要也不想使用Fake进行测试。
- 我目前的解决方案是将测试可执行文件拆分为一个 假设备 ,另一个用于 RealDevice(真实设备) 它执行初始化,然后调用相同的测试代码。

TL;博士: 核心库 Foo公司 ,取决于 设备接口 ,具有多个实现。多个测试可执行文件,其中大多数可以与 设备接口 ,但其中一个实现需要在客户端代码中进行额外设置。

在我看来,这似乎是一个合理的复杂程度。但它产生了许多项目:

静态库:
- Foo公司
- RealDevice(真实设备) 实施
- 食品测试工具 (注:包括 假设备 实施)
- gtest (用于部分测试)
- 另一个解决方案中的库,需要 RealDevice(真实设备) 使用
可执行文件:
- 2. TestExe$i 我想要的每个测试可执行文件的项目

在我更习惯的*nix环境中,我会将代码划分为一个合理的目录树,其中很多“项目”都只是一个对象文件,或者是一个带有一些客户端代码的.cpp作为核心逻辑。

对于这种范围的解决方案,这是合理的项目数量吗? 这对我来说是一件可怕的事情。我经常发现我需要在六个不同的项目中改变一些设置,而且我发现越来越难以驾驭。目前,这仍然是可以管理的,但我不知道当我进入更大、更复杂的项目时,这将如何保持可行。 我能组织得更好吗?

(同样,我是VisualStudio的新手,所以问题可能是我不知道如何管理多个相关项目,而不仅仅是项目本身的数量。)

1 回复 | 直到 8 年前

1

4

Community 7 年前

尽管您所做的是非常标准的,而且对于您所描述的这样一个小项目,解决方案似乎完全标准。然而,Visual studio确实为有经验的开发人员提供了一些方法来尽量减少这些问题的影响:

build-configurations 和 property-sheets :
简而言之,为什么要为fakeDevice和RealDevice创建一个项目?

为“设备”创建一个项目,根据选择的配置构建fakeDevice或RealDevice的源。这还允许您在“测试”配置中启动项目,并自动加载fakeDevice,同时选择“调试”或“发布”将提供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...} 在我的日常操作中,我在调试配置中简单地“按播放”,但当发布时间到来(或特定版本需要测试)时,我会“批量构建”用于调试或打包的项目的正确组合。

这实际上意味着,尽管我已经(包括共享库)为一个版本生成了近30个二进制文件,但我的解决方案中只有三个项目。

测试可执行文件
至于单元测试可执行文件,我建议为这些文件创建一个单独的解决方案-VisualStudio没有问题同时打开多个解决方案-但是我有一个技巧

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

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

个人(固执己见)建议
在Nix、Windows和Apple系统中开发,这里有一个很好的布局比喻。 “Nix希望您创建自己的makefiles和文件夹布局,它假设您完全知道自己在做什么(在终端中!)布局成为你的玩物(有足够的shellscript)。
Windows/Visual studio被设计为对所有级别的用户、八岁的Visual basic学习程序或创建硬件驱动程序的经验丰富的C++开发人员开放。因此,界面设计得非常可扩展-“解决方案”中的“项目”是一个基本概念(许多初学者没有意识到你可以有多个项目。然而,如果你想要更多的选项 一种方法 就MS而言(在本例中是配置和属性表)——如果你写了一个makefile或创建了一个布局,你“做得不对”(在微软看来)。

如果你看一看过去几年来在windows生态系统中所带来的麻烦,你会倾向于理解这个问题。在'nix上,将apt/yum包中的几十个共享库作为依赖项安装是很好的!然而,Windows(感觉)拥有多个DLL是个坏主意。没有包管理器,所以要么依赖.Net,要么将单个boost dll打包到您的产品中。(这就是为什么我更喜欢windows上的静态链接)。

编辑:
当您有多个配置时,可以通过两种方式选择每个配置的源做什么和不做什么。

一:手动
右键单击解决方案资源管理器中的任何源文件并选择属性-在“常规”部分下,您可以选择“从生成中排除”(如果您进行分组选择并右键单击,则此操作有效。

二:XML魔力
如果打开vcxproj文件,您将得到格式良好的XML文件布局! 虽然处理包含、排除甚至其他选项的管理的确切条件超出了本文的范围,但可以找到基本细节 In this well worded stackoverflow question 以及 MDSN toolchain documentation