为什么我可以在 csproj 文件中的某些元素中使用某些环境变量，而不能在 msbuild 中的其他元素中使用某些环境变量？
以下奇怪的行为可能是什么原因造成的？我该如何找出这些问题？
我们结合使用 make 文件和 msbuild。
我有一个需要强命名的项目。我之前将 snk 设置为在项目文件中使用，如下所示：
<AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile>
其中 EnvironmentVariable 是在启动 shell 进行构建的批处理文件中定义的，如下所示：
set EnvironmentVariable='SomePath'
这工作正常。现在我需要能够更改字符串名称键，因此它在开发计算机和发布构建服务器上可以不同。有一个变量用于保存强名称密钥文件的完整路径，称为 StrongNameKeyFile。这是在 msbuild 环境中定义的，如果我将一些文本输出放入作为构建项目的 msbuild 任务一部分包含的目标或属性文件中，那么我可以看到此 StrongNameKeyFile 指向正确的位置。因此，我将 csproj 更改为具有以下内容：
<AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>
但是当我尝试编译时，它的计算结果为空，并且在构建过程中未指定 /keyfile。
我们还在 make 文件中定义了变量，这些变量也可以在 csproj 中访问。这些用于指向引用的 dll 的位置，以便它们在开发和构建计算机上可以不同。我知道这些设置是作为引用正确输出并且所有内容都编译的，但是如果我尝试在 AssemblyOriginatorKeyFile 元素中使用这些变量之一，那么它在该元素中计算为空，但在引用元素中工作。
为什么会这样？ AssemblyOriginatorKeyFile 是否以某种方式进行特殊处理？我怎样才能追踪到这个问题的原因呢？
What reasons could there be for the following strange behaviour, and how might I track down the issues?
We use a combination of make files and msbuild.
I have a project which needs to be strongly named. I was previously setting the snk to use in the project file like this:
<AssemblyOriginatorKeyFile>$(EnvironmentVariable)TheKeyName.snk</AssemblyOriginatorKeyFile>
where EnvironmentVariable was defined in the batch file that launched the shell for the build like this:
set EnvironmentVariable='SomePath'
and this worked ok. Now I need the string name key to be able to be changed, so it can be different on the dev machine and the release build server. There is a variable which exists to hold the full path to the strong name key file, called StrongNameKeyFile. This is defined in the msbuild environment, and if I put some text output in the targets or properties files that are included as part of the msbuild task which build the project then I can see that this StrongNameKeyFile points to the correct location. So I changed the csproj to have this instead:
<AssemblyOriginatorKeyFile>$(StrongNameKeyFile)</AssemblyOriginatorKeyFile>
but when I try and compile this is evaluating to empty and no /keyfile is specified during the build.
We also have variable defined in the make files and these can be accessed in the csproj as well. These are used to point to the locations of referenced dlls, so that they can be different on dev and build machines. I know that these are set as the references come out correctly and everything compiles, but if I try and use one of these variables in the AssemblyOriginatorKeyFile element then it evaluates to empty in that element, but works in the reference element.
Why might this be? Is AssemblyOriginatorKeyFile treated specially somehow? How can I go about tracking the cause of this down?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有充分的理由为什么会发生这种情况——正如你所知，它通常可以正常工作；很可能是链条上的什么东西把它掉到了地板上。
要尝试的一件事是通过 /p:StrongNameKeyFile=XX 显式传递它 - 这将消除环境变量及其从查询中的正确传播。
另一个潜在的事情是，当名称被其他东西使用时，某些东西正在破坏变量？
使用 /v:diag 运行，您将获得所有输入和/或变量更改时的转储。
或者，如果在 V4 上，请使用 MSBuild调试器
并购买Hashimi 等人的 MSBuild 书籍
There's no good reason why this should happen - as you know it normally Just Works; it's likely to be something in the chain dropping it on the floor.
One thing to try is explicitly passing it via /p:StrongNameKeyFile=XX - that would eliminate environment variables and the correct propagation thereof from your inquiries.
Another potential thing is that something is clobbering the variable as the name is used vy something else?
Run with /v:diag and you'll get dumps of all the inputs and/or variables as they change.
Or if on V4, use the MSBuild Debugger
And buy the Hashimi et al MSBuild book