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

我想将我的版本从使用Visual Studio SLN文件转移到使用MSBUILD sripts（我们正在接近SLN文件中的100个项目），但我不想双重维护SLN文件在Visual Studio中编辑代码。我可以使用MSBUILD脚本来替换SLN文件吗？

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

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

来源

2012-11-09 Jeff B

Visual Studio中已经产生的MSBuild脚本。它们位于项目文件夹中的'.csproj'文件中。只要设置了适当的环境变量和PATH，它们就可以直接从命令提示符运行MSBuild。 –

这并不能帮助我的情况。我正在寻找的是基于项目依赖关系自动生成SLN文件的东西。当我们分解我们的巨大SLN时，我们将有20-30个重叠的SLN文件，其中包含一些相同的子项目。如果我然后编辑A.DLL的项目并向B.DLL添加一个依赖项，我希望B.DLL自动包含在当前包含A.DLL的所有SLN文件中。 –

...或使用Visual Studio没有任何SLN文件的一些方法。但我的经验是，VS自动创建一个解决方案，即使你只是用它来编辑一个文本文件。 –

只要您依赖于引用项目（而不是编译的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-11 23:25:16 Pawel

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

项目引用使构建速度变慢，如果使用dll引用进行构建，则可以更快地构建，但要权衡您必须知道或确定依赖性顺序，然后才能确保混乱。

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

来源

2012-11-12 12:23:07

我写了一个工具，可以在2011年12月之前动态生成一个* .sln文件。不幸的是，由于这里的政治工作，我无法部署它。我们为我们的构建系统维护了600多个项目文件，这对于解决方案来说太疯狂了。至少你会尝试在IDE中加载一个解决方案。

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

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

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

来源

2013-01-08 12:07:27

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

我们一直将大型解决方案文件分割成多个相关项目中的较小项目。然后，您可以打开一个或两个视觉工作室来查看您想要处理的项目。

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

不需要生成动态解决方案。我担心这样做可能需要相当多的工作，而且你也会遇到这样的情况，即你经常在不同的动态生成的解决方案上工作，所以你永远不会记住事情的真相。通过一些固定的解决方案文件，您可以将项目组织到几个文件夹中，然后在您的脑海中掌握某种组织，以了解哪些地方会发生什么。有了一些体面的组织，我发现我只是偶尔需要同时打开和解决两个解决方案。

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

来源

2013-01-08 12:25:30

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

从他们wiki：

GYP最初创建，为构建铬生成原生IDE项目文件（Visual Studio中，Xcode中）。

[..]

此外，一些GYP的设计是由经验在谷歌与源全内置的大型项目通知[..]。与Chromium Embedded Framework，它被用来生成* .vcxproj和*的.sln文件为Visual Studio 2012在这种情况下工作时

我目前使用它，它会产生与259个项目一个解决方案文件。如果使用旧版本的Visual Studio，它还会生成* .vcproj文件。

作为一个方面说明，这是将项目文件保留在版本控制系统之外并快速获得任何新开发项目设置的好方法。

编辑：再次阅读您的问题后，我不认为您可以从MSBUILD脚本生成* .gyp文件，但它仍然值得转换工作。

编辑2：看一看另一种答案，也可以帮助，尤其是gypfy.py这似乎前途：https://stackoverflow.com/a/9387350/1412348

来源

2013-06-18 08:53:23 AntonyG

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

回答

相关问题