深圳网站建设的,网站设计申请书,企业网站必备模块,全球最顶尖的设计公司如果不是遇到#xff0c;真的不会想到#xff0c;代码世界的问题真是千奇百怪#xff0c;这次遇到的是 dotnet pack 打包文件版本号引起的问题。之前进行 nuget 打包都是在 Visual Studio build 时进行#xff0c;版本号时通过 .csproj 中的 VersionPrefix 指定#xff0c… 如果不是遇到真的不会想到代码世界的问题真是千奇百怪这次遇到的是 dotnet pack 打包文件版本号引起的问题。之前进行 nuget 打包都是在 Visual Studio build 时进行版本号时通过 .csproj 中的 VersionPrefix 指定没遇到问题。最近改为通过 shell 脚本在 linux 上打包开始的 shell 脚本是怎么写的dotnet pack -c Release /p:version$(git tag --sortcommitterdate | tail -1 )后来发现 dotnet pack 不能自动 build 项目这个问题不是从哪个版本的 .net core cli 开始出现的。为了解决这个问题在 dotnet pack 命令之前添加了 dotnet build 命令dotnet build -c Releasedotnet pack -c Release /p:version$(git tag --sortcommitterdate | tail -1 ) 采用这个脚本发包后最近几次发包遇到了奇怪的问题比如发布了 EnyimMemcached 2.2 包在引起该包的 A 项目中升级到 EnyimMemcached 2.2而 A 项目所引用的其他 nuget 包也引用了 EnyimMemcached 但引用的是旧版 EnyimMemcached 2.1.12 build 没问题运行时却报下面的错误整个应用都无法启动。System.IO.FileLoadException: Could not load file or assembly EnyimMemcachedCore, Version2.1.12.0, Cultureneutral, PublicKeyTokennull. The located assemblys manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)File name: EnyimMemcachedCore, Version2.1.12.0, Cultureneutral, PublicKeyTokennull at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)对于这样的依赖同一个包的不同版本问题.net core 中已经进行了有效解决如果存在版本冲突在 build 时就能发现比如 解决 .net core 中 nuget 包版本冲突问题 只要 build 通过基本不会出现上面的问题.net core runtime 会自动使用最高版本。而我们现在却遇到了这个 .net core 已经解决的问题让人莫名其妙无从下手。今天再次遇到这个问题时想到把包解开看看其中有没有与运行时相关的元数据信息。解开一看除了 dll 文件没有其他用于运行时的文件在查看这个 dll 文件的信息时发现了线索 不对文件版本号怎么是 1.0 打的明明是 2.2 的包Review 打包脚本后恍然大悟dll 文件是在 build 时生成的Build 时没有添加版本信息于是使用了默认版本号1.0。赶紧改进脚本试试VERSION$(git tag --sortcommitterdate | tail -1)dotnet build /p:version$VERSION -c Release Enyim.Cachingdotnet pack -c Release /p:version$VERSION Enyim.Caching这样改进后打出的包中的 dll 文件版本就与包的版本就一致了在项目中升级到这个包问题也就解决了。原来.net core 在 build 时只检查 nuget 包的版本号不检查包中 dll 程序集文件的版本号而 .net core runtime 在运行时会检查程序集文件的版本号。而我们遇到的问题就是由于 build 时与运行时的检查机制不一致造成错误的文件版本号没有在 build 时被检查出来从而在应用运行的时候才发现大大增加了问题的排查难度。为什么一定要在运行时检查程序集文件的版本号而且在版本号出现问题时让整个应用都无法启动反正就这一个文件写个告警日志继续用这个文件就是了如果无法使用这个文件再让整个应用挂掉也不迟这个地方有点想不通。今天的发现也让之前的另外一个疑问有了答案之前在 .NET Core 2.2 中遇到了 System.Data.SqlClient 的问题想看看最新版的 corefx 是否解决了这个问题于是签出最新版的 corefx 代码 build 出了 System.Data.SqlClient.dll 替换 .NET Core 2.2 中的同名文件运行时也总是报错 Could not load file or assembly 只有签出 release/2.2 分支的代码 build 才行原来也是文件版本号的问题只要修改一下文件版本号就能解决。另外程序集的依赖信息保存在 .deps.json 文件中如果不能修改程序集文件的版本号应该可以通过修改 .deps.json 文件中 runtime 配置的 fileVersion 值来实现。runtime: {lib/netstandard2.0/EnyimMemcachedCore.dll: {assemblyVersion: 2.2.2.0,fileVersion: 2.2.2.0 }}原文地址https://www.cnblogs.com/dudu/p/10880845.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
