我可以使用 MSBUILD 脚本替换 SLN 文件吗？答案

【问题标题】：Can I use MSBUILD scripts to replace SLN files?我可以使用 MSBUILD 脚本替换 SLN 文件吗？
【发布时间】：2012-11-09 00:26:05
【问题描述】：

我想将我的构建从使用 Visual Studio SLN 文件转移到使用 MSBUILD sripts（我们在 SLN 文件中接近 100 个项目），但我不想在我们的时候双重维护 SLN 文件在 Visual Studio 中重新编辑代码。

我想要创建一个 MSBUILD 脚本的依赖树，然后能够从 Visual Studio 中选择任何一个 MSBUILD 脚本来使用，就好像它是 SLN 文件一样 - 自动包括所有依赖项目。

Visual Studio 可以做到这一点吗？是否有任何现有工具可以从 MSBUILD 脚本动态创建 SLN 文件？有没有人尝试编写一个工具来做到这一点？

【问题讨论】：

Visual Studio 已生成 MSBuild 脚本。它们位于项目文件夹中的 .csproj 文件中。只要设置了正确的环境变量和 PATH，它们就可以直接在命令提示符下使用 MSBuild 运行。
这对我的情况没有帮助。我正在寻找的是基于项目依赖关系自动生成 SLN 文件的东西。当我们分解庞大的 SLN 时，我们将拥有 20-30 个重叠的 SLN 文件，其中包含一些相同的子项目。如果我随后为 A.DLL 编辑项目并将依赖项添加到 B.DLL，我希望 B.DLL 自动包含在当前包含 A.DLL 的所有 SLN 文件中。
...或以某种方式在没有任何 SLN 文件的情况下使用 Visual Studio。但我的经验是，即使你只是用它来编辑文本文件，VS 也会自动创建一个解决方案。

标签： visual-studio-2010 visual-studio visual-studio-2012 msbuild solution

【解决方案1】：

只要您依赖引用项目（而不是编译的 dll）并且您有一些 Xml 经验，创建这样的东西应该不会太难。您将解析初始 csproj 文件（即 Xml）并读取对项目的所有引用。它们看起来像这样：

<ProjectReference Include="..\..\src\Test\Test.csproj" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Project>{ab709f59-aa17-4297-b827-101d086586e1}</Project>
  <Name>Test</Name>
</ProjectReference>

如您所见，您已经获得了相关 csproj 文件的路径。您将收集到相关项目的所有路径并递归地对每个路径执行相同的操作，直到您处理所有文件（小心从多个项目（重复）引用的项目 - 否则您将进入无限循环）。请注意，csproj 元素属于非空命名空间，因此在解析 Xml 时需要考虑这一点（.NET Xml API 可以处理这些）。您可以收集所有项目（路径、名称、GUID），然后创建 sln 文件，或者您可以即时创建 - 每次找到新参考时。

【讨论】：

【解决方案2】：

您可以按原样构建您的 csproj，如果您创建一个包含所有 csproj 的项目组并将其传递给 msbuild，则为您确定依赖顺序（只要您有项目引用而不是 dll 引用）。自动。

项目引用会导致构建速度较慢，如果使用 dll 引用构建，则构建速度会快得多，但代价是您必须知道或确定依赖顺序，然后才能确保混乱。

一个 sln 中的 100 个项目很多，会让你 VS 变慢。我倾向于每个实体都有一个 sln，例如网站、网络服务，而不是单一的构建和 sln。

【讨论】：

【解决方案3】：

早在 2011 年 12 月，我就编写了一个动态生成 *.sln 文件的工具。不幸的是，由于工作中的政治原因，我无法部署它。我们为我们的构建系统维护了 600 多个项目文件，这对于解决方案来说太大了。好吧，至少是您实际尝试在 IDE 中加载的解决方案。

尽管如此，我们确实使用了由 MSBuild（不是 Devenv.exe）加载的动态生成的解决方案文件。据我所知，没有人尝试在 IDE 中加载该解决方案文件。

无论如何，所以我编写的工具将包含我们的源代码的目录作为参数。它递归地搜索并找到其中的所有 *.vcxproj 和 *.csproj 文件。然后对于每个项目文件，它使用 MSBuild API 解析文件。当它解析每个文件时，它会查找其他项目文件之间的依赖关系。找到 *.lib 文件的本地依赖项足够聪明。找到托管 c++/CLI 的依赖项是足够聪明的，这些依赖项在代码文件本身中指定依赖项，例如：#using。它也很聪明，可以使用程序集引用找到正常的托管依赖项。它还通过其他几种方式找到依赖关系。

然后它会获取所有这些依赖项并生成一个解决方案文件。如果您有任何问题，请随时联系我，我们可以谈谈。

【讨论】：

【解决方案4】：

我不知道任何现有的工具。我知道这可能无法直接回答您的问题，但我可以分享一下我在大型项目中工作的经验。

我们总是将大型解决方案文件拆分为多个较小的相关项目。然后，您可以打开一两个视觉工作室来查看您想要从事的项目。

然后我们有一个 msbuild 脚本，它依次构建每个解决方案以生成整个产品和安装程序。

不需要动态解决方案生成。我担心维护这样的东西可能需要相当多的工作，而且你会遇到这样的情况，你不断地研究不同的动态生成的解决方案，所以你永远不会记得事情在哪里。使用一些固定的解决方案文件，您可以将项目组织到几个文件夹中，然后您就可以在脑海中对什么去哪里进行某种组织。有了一些体面的组织，我发现我只是偶尔需要同时打开并处理两个解决方案。

我们有一个或多个基础/核心解决方案，其中包含具有在其他解决方案之间共享的定义的项目。但是，我没有发现有必要从基础复制所有依赖项目以及使用它们的更高项目。您仍然可以通过依赖项目进行调试，而无需将它们包含在解决方案中。如果您确实需要进行更改，请打开基础解决方案并对其进行编辑和构建，然后继续。

【讨论】：

【解决方案5】：

查看GYP（生成您的项目），由 Google 为此目的创建（创建项目和解决方案文件）并在必要时自动构建。

来自他们的wiki：

GYP 最初是为了生成用于构建 Chromium 的原生 IDE 项目文件（Visual Studio、Xcode）。

[..]

此外，gyp 的一些设计灵感来自于 Google 拥有完全从源代码构建的大型项目 [..]。

我目前在处理 Chromium Embedded Framework 时使用它，它用于为 Visual Studio 2012 生成 *.vcxproj 和 *.sln 文件。在这种情况下，它会生成一个包含 259 个项目的解决方案文件。如果使用旧版本的 Visual Studio，它还会生成 *.vcproj 文件。

附带说明一下，这是一种将项目文件排除在版本控制系统之外并为任何新开发人员快速设置项目的好方法。

编辑：再次阅读您的问题后，我认为您无法从 MSBUILD 脚本生成 *.gyp 文件，但仍然值得进行转换。

编辑 2： 看看另一个可能也有帮助的答案，尤其是看起来很有希望的 gypfy.py：https://stackoverflow.com/a/9387350/1412348

【讨论】：