【问题标题】:MSBuild shared .targets fileMSBuild 共享 .targets 文件
【发布时间】:2016-08-17 15:50:46
【问题描述】:

我有几个 .csproj 文件,我将在其中导入一个通用 .targets 文件,以扩展构建过程。这些项目位于不同的目录中。 .targets 文件位于解决方案目录中。如何参考 .targets 文件的位置来导入它?有一个解决方案目录属性,但如果开发人员只是构建一个项目,这将不起作用。我该怎么办?我正在使用 .NET 4.5 和 Visual Studio 2015。

【问题讨论】:

    标签: msbuild


    【解决方案1】:

    您认为项目不知道它所包含的解决方案,而且可以说它不应该知道。因此,从项目的角度来看,您无法以编程方式找出完全不相关的文件所在的位置。除了扫描整个文件系统之外。有一些替代方案:

    • 依赖正确的目录结构。无论如何,您已经这样做了,因为您使用的解决方案还需要在固定位置查找项目。因此,假设您有一个主项目目录,其中包含 projectA/a.vcxproj、projectB/b.vcxproj 和 solutionDir/ab.sln 和 solutionDir/my.targets 然后在 a 和 b 中 <Import Project="$(MSBuildProjectDirectory)..\solutionDir\my.targets"/>
    • 需要一个设置为目标文件位置的属性(或环境变量),然后使用<Import Project="$(SomeDir)\my.targets"/>
    • 将您的目标文件放在“已知”的 msbuild 位置,例如 Importbefore/ImportAfter 目录,例如提到的 here

    我曾经使用过所有这些,最后我认为第一个更好:你只需要坚持一个目录约定 - 对于项目你需要跨越多个目录或与公共共享的东西 - 就是这样。例如,我们有大量常见的 msbuild 文件,它们位于一个存储库中。开始一个新项目总是归结为创建一个目录,克隆公共文件目录并添加一个新的项目目录。这可以很容易地实现自动化,在典型的 CI 服务器上也能很好地工作。第二个选项也是可行的,但它依赖于正确设置的环境,该环境不太“独立”,如果开发人员开始在机器的全局环境变量设置和本地环境变量设置中输入变量,那么它会变得非常混乱,等等上。第三个也有类似的问题,但更糟糕的是,现在只有一个正确的位置。

    【讨论】:

    • 我在一个大型项目中工作,所以我无法控制目录结构。不幸的是 1 对我不起作用。所有文件都签入源代码控制,开发人员可以将文件放在他们喜欢的驱动器上的任何位置,因此 3 也不起作用。我会等着看是否有更多的答案,因为我来这里是为了避免 2,但这可能是我要去的方向。
    • 我遗漏了一些东西,为什么 1 不起作用?您说解决方案目录中的目标文件。该解决方案使用相对路径来查找项目,因此项目具有解决方案的固定相对路径,因此也具有目标文件。您是否有不属于解决方案的项目?
    • 项目在目录结构中处于不同的层次。有些是两层深,有些是三层......我想我可以在 .sln 文件上做存在条件来确定我所处的深度。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-04
    • 1970-01-01
    • 1970-01-01
    • 2022-06-30
    • 2017-10-12
    相关资源
    最近更新 更多