使用MSBuild导入模块化项目

我开发了一个大型MSBuild项目来构建解决方案的一部分。有很多事情在进行——XML解析/替换、Windows服务、远程复制等等。因此，尽管我尽了最大努力在注释中添加了修饰，但该文件的管理变得非常困难

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

但是，我在MSBuild的导入功能上读到的所有信息都是，应该使用它来导入可重用的目标，即-any-MSBuild项目不需要任何修改就可以使用的目标。我在这里创建的独立项目正好相反——特定于一个项目，如果与其他项目一起使用，则默认情况下会中断，除非修改

所以我想我要问的是，即使我能。。。我应该吗？为了组织一个大型项目而严格使用进口是否存在固有的危险？有更好的方法吗

---

谢谢

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

---

简言之：如果它降低了复杂性，你应该这样做。

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