2010-08-27 64 views
8

给出一个解决方案,其中:如何在不检查依赖关系的情况下构建C#项目?

  • 项目P1具有P2
  • 参考P2具有P3
  • 参考P3具有参考P4

当你调用的MSBuild是这样的:

msbuild.exe /v:m "c:\mysolution\p1\p1.csproj" 

msbuild检查所有项目依赖关系是建立关系如果有必要的话。典型的输出是:

Microsoft (R) Build Engine Version 4.0.30319.1 
[Microsoft .NET Framework, Version 4.0.30319.1] 
Copyright (C) Microsoft Corporation 2007. All rights reserved. 

    P4 -> c:\mysolution\P4\bin\Debug\P4.dll 
    p3 -> c:\mysolution\p3\bin\Debug\p3.dll 
    p2 -> c:\mysolution\p2\bin\Debug\p2.dll 
    p1 -> c:\mysolution\p1\bin\Debug\p1.dll 

就我而言,我知道存在依赖关系并且都是正确的。

有没有办法只构建项目p1.csproj而不验证依赖关系?解决方案可以使用msbuild或其他方法。

+0

我想知道....我可以调用C#编译器而不是msbuild并传递所有的参数?即使对于一个有很多引用和依赖关系的大型项目,它是否很难找出通过的参数? – Sylvain 2010-08-27 20:59:47

+0

相关问题:http://stackoverflow.com/questions/819031/how-to-decrease-msbuild-times – wmeyer 2010-08-27 21:37:34

+0

谢谢。我们已经使用带有msbuild(/ m选项)的多处理器版本,对我们来说,它会产生巨大的差异:接近2倍的速度。 – Sylvain 2010-08-27 21:43:28

回答

4

你可以通过/p:BuildProjectReferences=false到的MSBuild,这将跳过建设项目refence .. 但是这有一个限制,如果您的解决方案配置和引用的项目的配置不匹配,的MSBuild将未能解决引用的项目的目标输出文件...

这里是一个免费的VS扩展包,你可以下载和试用 http://visualstudiogallery.msdn.microsoft.com/98de4058-8dc7-435b-9e01-c0f71dace808

VS包:夏普构建工具

我这个扩展的作者,我对目前的工作同样的要求,享受这个工具...

从本质上来说,这个扩展可以处理上面的情况,它将生成你的构建项目文件的影子副本,将所有项目引用更改为dll文件引用,并使用影子项目文件启动msbuild。

2

目标是什么(为什么你在乎)?

您可以使用程序集引用而不是项目引用(但要注意调试v版本路径差异)。

+0

我很关心,因为在一个有100个项目的解决方案中,这一步需要很长时间;比编译我感兴趣的项目多10倍。更改解决方案的结构或使用汇编引用对我来说不是好选择。 – Sylvain 2010-08-27 20:25:53

+0

这不是我在我的机器上看到的。如果在我的项目上运行msbuild,大约需要30秒才能发现无事可做。如果我立即再做一次,则需要30秒。它是检查需要时间的依赖性的过程。这就是为什么我想跳过这一部分。 – Sylvain 2010-08-27 20:35:55

+1

我很惊讶,表演很糟糕。您可能需要打开MSBuild诊断程序来确定需要花费多长时间。最新的检查应该很快,特别是如果事情确实是最新的。工具\选项\项目和解决方案\构建和运行将MSBuild输出冗长度更改为'诊断',做30秒的动作,并观察输出窗口(以及后来的冲刷)以找到'慢'操作。 – Brian 2010-08-27 20:53:12

1

也许你可以在Visual Studio中使用配置管理器,并取消选中除了想要构建的项目之外的所有项目。

+0

我需要一个解决方案,可以在不更改解决方案或项目的情况下工作。我需要这个从命令行工作。 – Sylvain 2010-08-27 20:38:48

+0

@Sly:为您的解决方案添加单独的配置。您可以从命令行中选择要构建的配置。这与经典* make *中的目标类似。例如。有一个配置*释放所有*,*全部调试*,*发布Subbranch *,*调试Subbranch *,... – 2010-08-27 21:26:24

0

退房微软的结构化解决方案和项目最佳实践:

Microsoft Patterns & Practices: Structuring Solutions and Projects

什么,你现在有一个是单一的解决方案。这是尽可能使用的理想情况。然而,单一解决方案对于像您这样的大型解决方案可能不切实际。

您可能想考虑对解决方案进行分区,即对依赖关系树的分区使用单独的解决方案。或者你甚至可以考虑使用所谓的多解决方案。查看链接的文章,了解这种变化的后果和缺点。也许使用更快的硬件可能是更好的选择。

+0

正如我在我对grefly的评论中所写的,我需要一个解决方案,无需更改解决方案或projets。 – Sylvain 2010-08-27 20:53:19

+0

顺便说一句,我们过去有多个解决方案(几年),但是当你这样做时,你必须对所有的重构工具说“很好”,并且“找到引用”和“定义”,这是最糟糕的,然后是长时间的构建时间。 – Sylvain 2010-08-27 20:54:26

+0

@Sly:1.)分区解决方案在不修改现有解决方案和项目的情况下工作,它只是为分区树的子分支添加解决方案。 2.)对不起,但你不能同时拥有。对于重构和*查找引用*来工作,必须加载所有源代码,即您必须使用项目引用。这是尽可能使用单一解决方案的原因之一(主要原因是让您的依赖始终保持最新,并且在正确的版本中并且随时可以调试)。 – 2010-08-27 21:01:34

0

您应该查看一个名为OpenMake的产品。我的首席建造工程师告诉我他们已经完成了很多依赖检查并建立了并行化。

OpenMake

相关问题