时间戳

首页 > 解决方案 > 为什么环境变量 BUILD_NUMBER 在构建过程中会干扰 .NET 引用？

.net - 为什么环境变量 BUILD_NUMBER 在构建过程中会干扰 .NET 引用？

问题描述

我从命令行调用 MSBuild：

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe" /t:clean,build /p:configuration="Release" /p:platform="Any CPU" MySolution.sln

该解决方案包含多个项目和 nuget 包引用。例如 Project1 通过 nuget 引用 log4net。Project2 引用 Project1。

引用被配置为本地复制，因此我在 Project1 的 bin 文件夹以及 Project2 的 bin 文件夹中获得了 log4net DLL。

但是，当我从 Jenkins 触发构建时，我总是会错过辅助引用，即在 Project2 的 bin 文件夹中，我找到了 Project1 的 DLL，但没有找到 log4net——尽管 log4net 存在于 Project1 的 bin 文件夹中。

我能够将原因追溯到 Jenkins 自动设置的环境变量 BUILD_NUMBER（例如 10）的存在。我在控制台窗口中进行了测试：如果它在那里，那么问题就如所描述的那样出现。如果不存在，所有 DLL 都在我期望的位置。

我该如何继续？欢迎任何建议！

提前致谢！

莱因哈德

标签： .netjenkinsmsbuild

解决方案

抱歉打扰了，我自己造成了这个问题，就像这样：

我为 Project1 创建了一个构建后事件挂钩，它仅在设置了环境变量 BUILD_NUMBER 时才进行一些二进制保护。完成后，MSBuild 在 Project1 的 ResolveAssemblyReferences 步骤中失败，因为它无法发现受保护程序集中的引用。

学过的知识 ;）

推荐阅读