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

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

目录

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

---

目录

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上一直通不过。

• 查看日志检查根本问题

  项目“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工作副本

---

微信扫一扫二维码关注订阅号杰哥技术分享

本文地址：https://www.cnblogs.com/Jack-Blog/p/10439325.html

作者博客：杰哥很忙

欢迎转载，请在明显位置给出出处及链接