1

I would like to move my builds from using Visual Studio SLN files to using MSBUILD sripts (we're approaching 100 projects in the SLN file), but I don't want to dual-maintain the SLN files for when we're editing code within Visual Studio.

What I would like is to create a dependency-tree of MSBUILD scripts, and then be able to select any one MSBUILD script from Visual Studio to use as if it were the SLN file - including all dependent projects automatically.

Can Visual Studio do this? Are there any existing tools that can dynamically create SLN files from MSBUILD scripts? Has anybody tried to write a tool to do this?

4

5 回答 5

1

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

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

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

于 2012-11-12T12:23:07.080 回答
1

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

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

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

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

于 2013-01-08T12:07:27.430 回答
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 文件，或者您可以即时创建 - 每次找到新参考时。

于 2012-11-11T23:25:16.890 回答
0

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

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

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

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

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

于 2013-01-08T12:25:30.527 回答
0

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

从他们的维基：

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

[..]

此外，gyp 的一些设计是从谷歌的经验中获得的，这些项目完全是从源代码构建的 [..]。

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

作为旁注，这是将项目文件排除在版本控制系统之外并为任何新开发人员快速获取项目设置的好方法。

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

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

于 2013-06-18T08:53:23.257 回答