使用 MSBuild Import 模块化项目
我开发了一个大型 MSBuild 项目来构建我们解决方案的一部分。发生了很多事情——XML 解析/替换、Windows 服务、远程复制等。因此，尽管我尽了最大努力在注释中添加装饰，但该文件变得非常难以管理。
作为一个错误，我将主要功能块分解为单独的文件，例如“XML.targets”、“Services.targets”等，并将它们导入到主“Build.proj”中。构建仍然有效，我立即发现它更易于管理。
然而，我读到的有关 MSBuild 导入功能的所有信息是，它应该用于导入可重用目标，即那些可以由任何 MSBuild 项目使用而无需任何修改的目标。我在这里创建的单独项目是相反的——特定于一个项目，如果与其他任何项目一起使用，除非进行修改，否则默认情况下将会中断。
所以我想我要问的是，即使我可以...应该我吗？严格使用导入来组织大型项目是否存在固有的危险？有更好的方法吗？
谢谢
I have developed a large MSBuild project to build a portion of our solution. There's a lot of things going on-- XML parsing/replacing, Windows services, remote copy, etc. As a result, the file has grown really difficult to manage, despite my best efforts to add decorations in comments.
As a goof, I broke out the main chunks of functionality out into separate files, like "XML.targets", "Services.targets", etc and imported them into the main "Build.proj." The build still worked and I immediately found it to be much more manageable.
However, all the info I have read on the Import feature of MSBuild is that it should be used to import reusable targets, ie those than can be consumed by -any- MSBuild project without any modifications. The separate projects I'm creating here are the opposite-- specific to one project and will break by default if use with anything else unless modified.
So I guess what I'm asking is, even though I can... should I? Is there an inherent danger in using Import strictly for the purpose of organizing a large project? Is there a better way to do this?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，不存在固有的危险。我认为将大型项目拆分为特定于某些操作的多个 .targets 文件是一个很好的决定，因为它降低了整体复杂性。创建可重用目标的想法意味着它们应该尽可能少地依赖其他部分。通过类比，您可以将单独的 .targets 文件视为类。它们的耦合越少越好。因为修改一个目标文件不太可能破坏整个过程。您可以拿一张纸，将目标文件绘制为点，并将主项目放在中心，并绘制它们之间的所有连接。假设一个目标文件覆盖了另一个目标文件，或者需要它的某些属性，或者以其他方式依赖于它，那么就存在连接。在完美的情况下，你会得到像星星一样的东西。
简而言之：如果它可以降低复杂性，您应该这样做。
No, there is no inherent danger. I think it's a good decision to split large project into several .targets files specific to certain operation since it reduces overall complexity. The idea of creating reusable targets means that they should have as little dependencies on the other parts as possible. By analogy you can think of separate .targets files as classes. The less coupled they are - the better. Because modification in one targets file will less likely break the whole process. You can take a peace of paper, draw your targets files as points with your main project in the center and draw all the connections between them. Say if one targets file overrides target from another or expects some properties from it or somehow else depends on it then there is a connection. In the perfect scenario you'll get something like a star.
In short: you should if it reduces complexity.