Jenkins持续集成学习-搭建jenkins问题汇总

目录

• Jenkins持续集成学习5-搭建jenkins问题汇总
  • 目录
  • 前言
  • 问题列表
    • nuget还原包问题
    • 编译问题
    • SVN更新问题
  • 参考文档

Jenkins持续集成学习5-搭建jenkins问题汇总

---

目录

Jenkins持续集成学习-Windows环境进行.Net开发1
Jenkins持续集成学习-Windows环境进行.Net开发2
Jenkins持续集成学习-Windows环境进行.Net开发3
Jenkins持续集成学习-Windows环境进行.Net开发4
Jenkins持续集成学习-搭建jenkins问题汇总

前言

前面几篇文字讲解了在开发环境部署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,安装完成后解决。

编译问题

1. 使用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成功编译。

   同理编译VS2015(MSBuild 14.0)项目须要安装Microsoft Build Tools 2015。
   须要注意因为VS2017安装已经采用可选安装，所以再也不提供Microsoft Build Tools 2017工具,须要经过VS2017安装工具选择MSBuild工具安装
   

2. 因为VS2017支持以PackageReference方式引用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一文中和NuGet is now fully integrated into MSBuild提到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和Cannot find reference assemblies for .NET 3.5 or lower using core msbuild。

• jenkins环境变量问题。
  如今能够基本肯定是包路径问题，而为何命令行直接编译生成的配置文件和jenkins调用window命令生成的配置文件会不同呢，怀疑多是因为jenkins的环境变量和windows的环境变量不同致使的。
  原来package.config的包管理方式会将包下载到程序目录下，而PackageReference的包管理方式直接使用全局引用的方式，性能获得了极大提高，在管理全局包、缓存和临时文件夹一文提到关于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 引用文章中介绍了关于nuget配置获取与设置的方法。经过在nuget.config配置文件中添加globalPackagesFolder设置全局的nuget的包文件路径
  
  再次构建就成功了。

SVN更新问题

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

参考文档

1. Package Restore
2. NuGet is now fully integrated into MSBuild
3. Support for .NET Framework 3.5
4. Cannot find reference assemblies for .NET 3.5 or lower using core msbuild
5. 管理全局包、缓存和临时文件夹
6. nuget.config 引用
7. Jenkins：无效版本的SVN工做副本

---

本文地址：http://www.javashuo.com/article/p-pyqqwkbf-kp.html 做者博客：杰哥很忙 欢迎转载，请在明显位置给出出处及连接