代码之家  ›  专栏  ›  技术社区  ›  Sam Holder Brian Adams

为什么我可以在csproj文件中的某些元素中使用某些环境变量,而在msbuild中不使用其他元素?

  •  2
  • Sam Holder Brian Adams  · 技术社区  · 15 年前

    以下奇怪的行为可能有什么原因,我该如何追踪这些问题?

    我们使用make文件和msbuild的组合。

    <AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile> 
    

    其中EnvironmentVariable是在为生成启动shell的批处理文件中定义的,如下所示:

    set EnvironmentVariable='SomePath'
    

    这个效果不错。现在我需要能够更改string name键,这样在dev机器和release build服务器上就可以不同了。存在一个变量来保存强名称密钥文件的完整路径,称为StrongNameKeyFile。这是在msbuild环境中定义的,如果我将一些文本输出放在作为生成项目的msbuild任务的一部分包含的目标或属性文件中,则可以看到此StrongNameKeyFile指向正确的位置。所以我把csproj改成了这个:

    <AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>
    

    我们还在make文件中定义了变量,这些变量也可以在csproj中访问。它们用于指向引用的dll的位置,以便它们在开发人员和构建人员的计算机上可以不同。我知道这些都是在引用正确出现并且所有内容都编译时设置的,但是如果我尝试在assemblyOriginateWorkeyFile元素中使用其中一个变量,那么它在该元素中的计算结果为空,但在reference元素中起作用。

    为什么会这样?WorkyFile是否受到特殊对待?我怎样才能找到原因呢?

    1 回复  |  直到 15 年前
        1
  •  2
  •   Ruben Bartelink    15 年前

    没有充分的理由来解释为什么会发生这种情况——正如你所知道的那样,它通常只是起作用;很可能是链条上的什么东西掉在地上了。

    另一个潜在的问题是,当这个变量的名字被用在别的东西上时,有什么东西正在撞击这个变量?

    使用/v:diag运行时,您将得到所有输入和/或变量的转储。

    或者如果在V4上,使用 MSBuild Debugger

    Hashimi et al MSBuild book