将外部配置复制到 Visual Studio 中的本地项目？

Question

如果 Visual Studio 已经检测到来自另一个项目的构建配置，那么在大约 50-100 个项目（相同的解决方案）中创建构建配置的最简单方法是什么？

我们的团队在几个解决方案中使用了一组通用项目（命名空间只是“通用”）。 Common 命名空间有它自己的主解决方案和它自己的一组构建配置。 Common 的解决方案包含五个构建配置（“Debug-QA”、“Debug-Dev”等）。

每当在新解决方案（即“MyNewSolution”）中使用这些项目时，Visual Studio 都会显示来自 Common 主解决方案的构建配置。 不幸的是，这些配置尚未在 MyNewSolution 或 MyNewSolution 的任何项目中创建。 这会在将构建配置添加到其他项目或将项目包含在这些构建配置中时产生问题，因为如果名称已经存在，则无法创建构建配置（Visual Studio 认为它确实存在，感谢 Common包含的项目）。

我的目标是将相同的配置（即“Debug-QA”、“Debug-Dev”等）添加到 MyNewSolution 及其项目中，以便所有项目和解决方案匹配。 我能看到的唯一方法是在每个新项目上手动创建构建配置……这是一种折磨，因为 MyNewSolution 有大约 50-100 个项目。

仅供参考：我使用的是 Visual Studio 2012

Answer 1

这与其说是一个适当的解决方案，不如说是一种黑客攻击，但您始终可以：

1. 为整个解决方案创建所需配置的副本，并将 GUID 作为其名称。
2. 从已经具有原始配置的项目中删除副本（撤消更改）。
3. 使用“在文件中查找/替换”工具将 GUID 重命名为原始配置的名称。

即使它不是一个非常可行的选择，它也是一个很好的快速解决方案。

编辑：

如何从解决方案中手动删除配置：

在文本编辑器中打开解决方案文件后，您将看到一个名为Global的块，其中包含部分。 SolutionConfigurationPlatforms部分包含配置的定义。 还有一个名为ProjectConfigurationPlatforms部分，其中分配了配置。 只需从两个组中删除对配置的引用即可。 如果您有更复杂的解决方案，则可能需要删除其他引用。 这只是一个基本情况。

如何从项目中手动删除配置：同样，在文本编辑器中打开项目文件后，您将看到许多对要删除的配置的引用。 C# 项目有一个以配置为条件的PropertyGroup 。 您可以简单地完全删除该组。 可能还有其他对文件周围配置的引用，因此请确保正确清理所有内容。

如果出现问题，请确保您有文件备份。

Answer 2

如果目标配置的项目级自定义非常少，这可能是通过 MSBuild Import元素导入到您的各个项目中的外部化配置来管理的最简单方法。

为了允许特定于项目的覆盖，此导入应放置在项目文件顶部附近。 例如：

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="..\..\CommonConfig.targets" Condition="Exists('..\..\CommonConfig.targets')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    ...

不幸的是，这需要您编辑所有项目文件一次以添加Import . 但是，一旦完成，您就可以向导入的.targets文件添加配置，并让它自动传播到所有项目。

Answer 3

我无法告诉您什么最适合您，但我可以根据经验说，当您不让 Visual Studio 编写项目文件时，从旧解决方案空间创建包含 50 多个项目的新解决方案空间变得非常容易。 相反，您可以使用现成的第三方软件，该软件会读取您提供的一些配置文件，并在几秒钟内生成解决方案和您需要的所有项目，所有这些都按照您需要的方式进行配置。

当您只想编译公共项目时，相同的软件也会生成独立的“公共”解决方案。

当您设置项目时，正确的软件将为您提供 makefile 提供的灵活性和功能，但您仍然可以在 Visual Studio 中完成您的工作。

我在这个角色中广泛使用了 CMake，但用于 C++ 而不是 C#。 我对 CMake 很满意； 我已经在 50 多个项目的环境中使用了它，这些项目的源代码分散得非常广泛，以至于我使用脚本来查找所有内容，以及一些作为预编译 DLL 或 LIB 引入的第三方库。 此外，根据我的经验，我知道没有什么能阻止某人为相同的源代码同时维护他们自己手工制作的 VS 项目文件集，如果他们真的想要的话。 但当然，您可能希望自己购买最适合您环境的软件。

将几十个项目从手工制作的项目文件转换为更像 makefile 的系统是一项重大的时间投资，但在需要多次重新配置或重新组合项目的环境中，我觉得投资回报相当快。