时间:2010-11-24 19:04:21

标签: msbuild import modularity

我开发了一个大型MSBuild项目来构建我们解决方案的一部分。有很多事情发生 - XML解析/替换,Windows服务,远程复制等等。因此,尽管我尽最大努力在评论中添加装饰,但文件仍然变得非常难以管理。

作为一个混蛋,我将主要的功能块分解为单独的文件,如“XML.targets”,“Services.targets”等,并将它们导入主“Build.proj”。构建仍然有效,我立即发现它更易于管理。

但是,我在MSBuild的导入功能上阅读的所有信息都是它应该用于导入可重用目标,即可以被-any- MSBuild项目使用而不需要任何修改的目标。我在这里创建的单独项目是相反的 - 特定于一个项目,如果使用其他任何东西,除非被修改,否则将默认中断。

所以我想我要问的是,即使我可以 ... 应该我?严格使用Import是否存在组织大型项目的固有危险?有更好的方法吗?

由于

1 个答案:

答案 0 :(得分:1)

不,没有固有的危险。我认为将大型项目拆分为特定于某些操作的几个.targets文件是一个很好的决定,因为它降低了整体复杂性。创建可重用目标的想法意味着它们应该尽可能少地依赖于其他部分。通过类比,您可以将单独的.targets文件视为类。耦合越少 - 越好。因为在一个目标文件中修改将不太可能破坏整个过程。您可以使用纸张,将目标文件绘制为主要项目位于中心的点,并绘制它们之间的所有连接。假如一个目标文件覆盖另一个目标文件或者期望某些属性来自它或者某种其他方式取决于它,那么就有一个连接。在完美的场景中,你会得到像星星一样的东西 简而言之:如果降低复杂性