我想将我的构建从使用Visual Studio SLN文件移动到使用MSBUILD sripts(我们正在接近SLN文件中的100个项目),但我不希望双重维护SLN文件。在Visual Studio中重新编辑代码。
我想要的是创建一个MSBUILD脚本的依赖树,然后能够从Visual Studio中选择任何一个MSBUILD脚本,就好像它是SLN文件一样 - 包括所有依赖项目。
Visual Studio可以这样做吗? 是否有任何可以从MSBUILD脚本动态创建SLN文件的工具? 有没有人试图写一个工具来做到这一点?
答案 0 :(得分: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文件的路径。您将收集相关项目的所有路径,并以递归方式对每个路径执行相同操作,直到您处理所有文件(小心从mutliple项目引用的项目(重复项) - 否则您将进入无限循环)。请注意,csproj元素属于非空命名空间,因此在解析Xml时需要考虑这一点(.NET Xml API可以处理这些)。您可以收集所有项目(路径,名称,GUID),然后创建sln文件,或者您可以在每次找到新参考时动态执行。
答案 1 :(得分:1)
您可以按原样构建csproj,如果您创建了所有csproj的项目组并将其传递给msbuild,则为您确定依赖顺序(因为您有项目引用而不是dll引用)。 Automajically。
项目引用会使构建速度变慢,如果使用dll引用构建,则可以更快地构建,但权衡是您必须知道或确定依赖顺序,然后可以确保混乱。
sln中的100个项目很多,会让你VS慢。我倾向于每个实体都有一个sln,例如网站,网络服务而不是整体构建和sln。
答案 2 :(得分:1)
我在2011年12月编写了一个动态生成* .sln文件的工具。不幸的是,由于这里的政治工作,我无法部署它。我们为构建系统维护了600多个项目文件,这对于解决方案来说太疯狂了。至少你实际上会尝试在IDE中加载一个解决方案。
尽管如此,我们确实使用了由MSBuild(Not Devenv.exe)加载的动态生成的解决方案文件。据我所知,没有人试图在IDE中加载该解决方案文件。
无论如何,所以我编写的工具将包含我们源代码的目录作为参数。它以递归方式搜索并查找其中的所有* .vcxproj和* .csproj文件。然后,对于每个项目文件,它使用MSBuild API解析文件。当它解析每个文件时,它会查找其他项目文件之间的依赖关系。它足够聪明,可以找到* .lib文件的本机依赖项。它足够聪明,可以找到托管c ++ / CLI的依赖项,它们在代码文件本身中指定依赖项,例如:#using。使用程序集引用找到正常的托管依赖项也足够聪明。它还可以通过其他几种方式找到依赖关系。
然后它接受所有这些依赖项并生成解决方案文件。如果您有任何问题请随时给我打电话,我们可以聊聊。
答案 3 :(得分:0)
我不知道任何现有的工具。我知道这可能不直接回答你的问题,但我可以分享我在大型项目上工作的经验。
我们总是将大型解决方案文件拆分为许多较小的相关项目。然后,您可以打开一个或两个视觉工作室来查看您想要处理的项目。
然后我们有一个msbuild脚本,它依次构建每个解决方案以生成整个产品和安装程序。
不需要生成动态解决方案。我担心维护这样的事情可能需要相当多的工作,而且你也会遇到这样的情况:你经常处理不同的动态生成的解决方案,所以你永远不会记住事情的位置。通过一些固定的解决方案文件,您可以将项目组织到几个文件夹中,然后您就可以了解某些组织的内容。通过一些体面的组织,我发现我偶尔也需要同时打开和处理两种解决方案。
我们有一个或多个基础/核心解决方案,其中包含具有其他解决方案之间共享定义的项目。但是,我没有发现有必要从使用它们的高级项目中复制基础中的所有依赖项目。您仍然可以通过依赖项目调试自己的方式,而无需在解决方案中使用它们如果您确实需要进行更改,请打开基础解决方案并进行编辑和构建,然后继续进行。
答案 4 :(得分:0)
查看由Google创建的GYP(生成您的项目)(创建项目和解决方案文件),并在必要时自动化构建。
来自wiki:
最初创建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