目录

* Jenkins持续集成学习5-搭建jenkins问题汇总
<https://www.cnblogs.com/Jack-Blog/p/10439325.html#jenkins持续集成学习5-搭建jenkins问题汇总>
* 目录 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#目录>
* 前言 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#前言>
* 问题列表 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#问题列表>
* nuget还原包问题 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#nuget还原包问题>
* 编译问题 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#编译问题>
* SVN更新问题 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#svn更新问题>
* 参考文档 <https://www.cnblogs.com/Jack-Blog/p/10439325.html#参考文档>
Jenkins持续集成学习5-搭建jenkins问题汇总

目录

Jenkins持续集成学习-Windows环境进行.Net开发1
<https://www.cnblogs.com/Jack-Blog/p/10291612.html>
Jenkins持续集成学习-Windows环境进行.Net开发2
<https://www.cnblogs.com/Jack-Blog/p/10316116.html>
Jenkins持续集成学习-Windows环境进行.Net开发3
<https://www.cnblogs.com/Jack-Blog/p/10331263.html>
Jenkins持续集成学习-Windows环境进行.Net开发4
<https://www.cnblogs.com/Jack-Blog/p/10346032.html>
Jenkins持续集成学习-搭建jenkins问题汇总 <https://www.cnblogs.com/Jack-Blog/p/10439325.html>

前言

前面几篇文字讲解了在开发环境部署jenkins并通过SVN、Github、Gitlab进行持续集成。

由于工作需要,需要在一个干净的服务器上部署jenkins用于测试环境的持续集成。由于我本地的开发环境基本的环境及插件都已经存在了,因此部署的时候没有碰到任何问题,但是在一个干净的开发环境部署的时候碰到了许多问题,且存在部分问题在网络上找不到解决办法,最终自己解决。

问题列表

nuget还原包问题

nuget重置包的时候报错,未经处理的异常: System.TypeLoadException: 未能从程序集“mscorlib,
Version=4.0...
由于很多项目仍然使用的是.net framework 3.5,因此仍然需要用msbuild
工具进行编译,通过反编译可以看到我当前使用的4.9版本的nuget使用的是.net framework 4.6版本,而服务器上没有安装.net
framework 4.6,安装完成后解决。


编译问题

*
使用12.0版本的MSBuild编译报错。MSBUILD : error MSB1025: An internal failure occurred
while running MSBuild.
原因:没有安装MSBuild编译工具,我从我本地开发环境直接拷贝MSBuild工具C:\Program Files
(x86)\MSBuild\12.0\Bin到服务器,调用MsBuild命令报错Could not load file or assembly
'System.Threading.Tasks.Dataflow'...,最后通过安装Microsoft Build Tools 2013
<https://www.microsoft.com/en-US/download/details.aspx?id=40760>成功编译。

同理编译VS2015(MSBuild 14.0)项目需要安装Microsoft Build Tools 2015
<https://www.microsoft.com/en-us/download/details.aspx?id=48159>。
需要注意由于VS2017安装已经采用可选安装,因此不再提供Microsoft Build Tools 2017工具,需要通过VS2017安装工具
<https://visualstudio.microsoft.com/zh-hans/downloads/>选择MSBuild工具安装


*
由于VS2017支持以PackageReference
<https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html>
方式引用nuget包。通过PackageReference的方式引用在Nuget包还原的时候会在obj目录下自动生成Nuget包引用的配置文件
project.assets.json、AsyncModule.NetMQ.2017.csproj.nuget.cache、
AsyncModule.NetMQ.2017.csproj.nuget.g.props、
AsyncModule.NetMQ.2017.csproj.nuget.g.targets。
但是在本地使用Nuget Restore进行包还原后,在通过MSBuild编译可以通过,但是在Jenkins上一直通不过。

*
查看日志检查根本问题
log
项目“D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj”(2)正在节点
1 上生成
“D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj”(2:2)
(Build 个目标)。 15:23:53 C:\Program
Files\dotnet\sdk\2.2.103\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5):
error NETSDK1064: 未找到版本为 0.1.26 的包 AsyncIO。它可能已在 NuGet 还原后删除。否则,NuGet
还原可能只是部分完成,这种情况可能是最大路径长度限制所导致。
[D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]

由于之前对于VS2017新的包引用方式不是很理解,且被其他文章误导认为 project.assets.json
只是存放包的依赖关系,认为它是在VS中引用包时生成的,而实际该配置文件以及obj下其他三个名为*.csproj.nuget*
的配置文件都是在Nuget包还原的时候自动创建的。

由于Jenkins一直报错说找不到包(路径可以肯定绝对没有超长),因此通过对比直接nuget命令创建的配置文件和jenkins创建的配置文件有什么差异。

左图是在本地通过命令行进行包还原创建的配置文件,右图是jenkins上调用命令行创建的配置文件。可以发现两个路径是不一样的。初步判断编译的时候会去配置的
packageFolders查找包而由于"C:\WINDOWS\system32\config\systemprofile\.nuget\packages\"
路径根本不存在,因此再去C:\Program Files\dotnet\sdk\2.2.103\Sdks下查找安装的SDK包目录,都找不到最终报错。

*
使用 dotnet build命令编译

在Package Restore
<https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore>一文中和
NuGet is now fully integrated into MSBuild
<https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html>
提到Nuget已经被集成到MSBuild了,因此在安装过.net core sdk可以直接通过dotnet build
命令编译自动重置nuget包。尝试使用结果报错
D:\Jenkins\workspace\AsyncModule.NetMQ-V2>dotnet build
AsyncModule.NetMQ\AsyncModule.NetMQ.2017.sln 用于 .NET Core 的 Microsoft (R)
生成引擎版本 15.9.20+g88f5fadfbe 版权所有(C) Microsoft Corporation。保留所有权利。 正在还原
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj
的包... 正在还原
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj
的包... 正在还原
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\AsyncModule.NetMQ.Test.2017.csproj
的包... 正在生成 MSBuild 文件
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\obj\AsyncModule.NetMQ.2017.csproj.nuget.g.props。
正在生成 MSBuild 文件
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\obj\AsyncModule.NetMQ.Test.2017.csproj.nuget.g.props。
正在生成 MSBuild 文件
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\obj\AsyncModule.NetMQ.Client.2017.csproj.nuget.g.props。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj
的还原在 223.01 ms 内完成。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Test\AsyncModule.NetMQ.Test.2017.csproj
的还原在 223.01 ms 内完成。
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj
的还原在 223.01 ms 内完成。 C:\Program
Files\dotnet\sdk\2.2.103\Microsoft.Common.CurrentVersion.targets(1179,5): error
MSB3644: 未找到框架“.NETFramework,Version=v3.5”的引用程序集。若要解决此问题,请安装此框架版 本的 SDK 或
Targeting Pack,或将应用程序的目标重新指向已装有 SDK 或 Targeting Pack
的框架版本。请注意,将从全局程序集缓存(GAC)解析程序集,并将使用这些程序集替换引用程序集。因此,程序集 的目标可能未正确指向您所预期的框架。
[D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ.Client.2017\AsyncModule.NetMQ.Client.2017.csproj]
C:\Program
Files\dotnet\sdk\2.2.103\Microsoft.Common.CurrentVersion.targets(1179,5): error
MSB3644: 未找到框架“.NETFramework,Version=v3.5”的引用程序集。若要解决此问题,请安装此框架版 本的 SDK 或
Targeting Pack,或将应用程序的目标重新指向已装有 SDK 或 Targeting Pack
的框架版本。请注意,将从全局程序集缓存(GAC)解析程序集,并将使用这些程序集替换引用程序集。因此,程序集 的目标可能未正确指向您所预期的框架。
[D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]
SocketSenderManager.cs(294,6): warning CS0162: 检测到无法访问的代码
[D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\AsyncModule.NetMQ.2017.csproj]
AsyncModule.NetMQ.2017 ->
D:\Jenkins\workspace\AsyncModule.NetMQ-V2\AsyncModule.NetMQ\bin\Debug\net40\AsyncModule.NetMQ.dll
可以发现编译之前确实自动还原了包,但是最后编译的时候报错error MSB3644:
未找到框架“.NETFramework,Version=v3.5”的引用程序集。实际我本地开发环境是安装过了.Net Framework 3.5,查找资料发现
dotnet build 不支持编译.net 3.5 framework,可以查看Support for .NET Framework 3.5
<https://github.com/joaomatossilva/DateTimeExtensions/issues/83#issuecomment-425572846>
和Cannot find reference assemblies for .NET 3.5 or lower using core msbuild
<https://github.com/Microsoft/msbuild/issues/1333#issuecomment-279922401>。

*
jenkins环境变量问题。

现在可以基本确定是包路径问题,而为什么命令行直接编译生成的配置文件和jenkins调用window命令生成的配置文件会不一样呢,怀疑可能是由于jenkins的环境变量和windows的环境变量不一样导致的。
原来package.config的包管理方式会将包下载到程序目录下,而PackageReference
的包管理方式直接使用全局引用的方式,性能得到了极大提升,在管理全局包、缓存和临时文件夹
<https://docs.microsoft.com/zh-cn/nuget/consume-packages/managing-the-global-packages-and-cache-folders>
一文提到关于global‑packages包路径。

global-packages 文件夹是 NuGet 安装任何下载包的位置。 每个包完全展开到匹配包标识符和版本号的子文件夹。
使用 PackageReference 格式的项目总是直接从该文件夹中使用包。 使用 packages.config 时,包将安装到
global-packages 文件夹,然后复制到项目的 packages 文件夹。
Windows:%userprofile%.nuget\packages
Mac/Linux:~/.nuget/packages
使用 NUGET_PACKAGES 重写环境变量 globalPackagesFolder 或 repositoryPath 配置设置(分别在使用
PackageReference 和 packages.config 时)或 RestorePackagesPath MSBuild 属性(仅限
MSBuild)。 环境变量优先于配置设置。

*
设置环境变量添加NUGET_PACKAGES路径


添加后必须重启jenkins才能生效。再次编译就成功了。

*
设置Jenkins内部环境变量添加NUGET_PACKAGES
既然是环境变量,那直接添加到jenkins内部即可,通过插件EnvInject Plugin可以设置Jenkins内置的环境变量,在Build
Environment勾选Inject environment variables to the build process
设置环境变量,这样设置不需要重启,但是每个job如果需要都需要额外设置环境变量。

17:14:06 [EnvInject] - Executing scripts and injecting environment variables
after the SCM step. 17:14:06 [EnvInject] - Injecting as environment variables
the properties content 17:14:06 userprofile=C:\Users\Dm_ca 17:14:06 17:14:06
[EnvInject] - Variables injected successfully. 17:14:06 [AsyncModule.NetMQ-V2]
$ cmd /c call C:\WINDOWS\TEMP\jenkins3711651605143255297.bat 17:14:06 17:14:06
D:\Jenkins\workspace\AsyncModule.NetMQ-V2>echo C:\Users\Dm_ca\.nuget\packages
17:14:06 C:\Users\Dm_ca\.nuget\packages
可以看到环境变量已经设置成功,同时编译也通过了。

*
设置nuget全局包文件夹
除了通过环境变量设置以外,还可以在nuget.config配置中设置全局包文件夹。在nuget.config 引用
<https://docs.microsoft.com/zh-cn/nuget/reference/nuget-config-file#config-section>
文章中介绍了关于nuget配置获取与设置的方法。通过在nuget.config配置文件中添加globalPackagesFolder
设置全局的nuget的包文件路径

再次构建就成功了。

SVN更新问题

jenkins检出的代码,若右键显示svn 升级工作副本,原因是Jenkins的SVN插件默认使用的是1.4版本的SVN客户端,在系统管理-系统设置
中找到SVN的配置修改为高版本即可。

参考文档

* Package Restore
<https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore>
* NuGet is now fully integrated into MSBuild
<https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html>
* Support for .NET Framework 3.5
<https://github.com/joaomatossilva/DateTimeExtensions/issues/83#issuecomment-425572846>
* Cannot find reference assemblies for .NET 3.5 or lower using core msbuild
<https://github.com/Microsoft/msbuild/issues/1333#issuecomment-279922401>
* 管理全局包、缓存和临时文件夹
<https://docs.microsoft.com/zh-cn/nuget/consume-packages/managing-the-global-packages-and-cache-folders>
* nuget.config 引用
<https://docs.microsoft.com/zh-cn/nuget/reference/nuget-config-file#config-section>
* Jenkins:无效版本的SVN工作副本 <http://www.voidcn.com/article/p-fprtguui-bta.html>
本文地址:https://www.cnblogs.com/Jack-Blog/p/10439325.html
<https://www.cnblogs.com/Jack-Blog/p/10439325.html>
作者博客:杰哥很忙
欢迎转载,请在明显位置给出出处及链接

友情链接
KaDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:[email protected]
QQ群:637538335
关注微信