如果不是遇到，真的不會想到，代碼世界的問題真是千奇百怪，這次遇到的是?dotnet pack?打包文件版本號引起的問題。

之前進行 nuget 打包都是在 Visual Studio build 時進行，版本號時通過 .csproj 中的?VersionPrefix 指定，沒遇到問題。

最近，改為通過 shell 腳本在 linux 上打包，開始的 shell 腳本是怎么寫的：

dotnet pack -c Release /p:version=$(git tag --sort=committerdate | tail -1 )

后來發(fā)現(xiàn)?dotnet pack 不能自動 build 項目，這個問題不是從哪個版本的 .net core cli 開始出現(xiàn)的。

為了解決這個問題，在 dotnet pack 命令之前添加了 dotnet build 命令：

dotnet build -c Release
dotnet pack -c Release /p:version=$(git tag --sort=committerdate | tail -1 )

采用這個腳本發(fā)包后，最近幾次發(fā)包遇到了奇怪的問題，比如發(fā)布了 EnyimMemcached 2.2 包，在引起該包的 A 項目中升級到?EnyimMemcached 2.2，而 A 項目所引用的其他 nuget 包也引用了?EnyimMemcached 但引用的是舊版?EnyimMemcached 2.1.12 ，build 沒問題，運行時卻報下面的錯誤，整個應(yīng)用都無法啟動。

System.IO.FileLoadException: Could not load file or assembly 'EnyimMemcachedCore, Version=2.1.12.0, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'EnyimMemcachedCore, Version=2.1.12.0, Culture=neutral, PublicKeyToken=null'
at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)

對于這樣的依賴同一個包的不同版本問題，.net core 中已經(jīng)進行了有效解決，如果存在版本沖突，在 build 時就能發(fā)現(xiàn)，比如?解決 .net core 中 nuget 包版本沖突問題?，只要 build 通過，基本不會出現(xiàn)上面的問題，.net core runtime 會自動使用最高版本。

而我們現(xiàn)在卻遇到了這個 .net core 已經(jīng)解決的問題，讓人莫名其妙，無從下手。今天再次遇到這個問題時，想到把包解開看看其中有沒有與運行時相關(guān)的元數(shù)據(jù)信息。

解開一看，除了 dll 文件，沒有其他用于運行時的文件，在查看這個 dll 文件的信息時發(fā)現(xiàn)了線索：

?

不對，文件版本號怎么是 1.0 ，打的明明是 2.2 的包？

Review 打包腳本后恍然大悟

dll 文件是在 build 時生成的，Build 時沒有添加版本信息，于是使用了默認(rèn)版本號1.0。

趕緊改進腳本試試

VERSION=$(git tag --sort=committerdate | tail -1)
dotnet build /p:version=$VERSION -c Release Enyim.Caching
dotnet pack -c Release /p:version=$VERSION Enyim.Caching

這樣改進后，打出的包中的 dll 文件版本就與包的版本就一致了

在項目中升級到這個包，問題也就解決了。

原來，.net core 在 build 時只檢查 nuget 包的版本號，不檢查包中 dll 程序集文件的版本號，而 .net core runtime 在運行時會檢查程序集文件的版本號。而我們遇到的問題就是由于 build 時與運行時的檢查機制不一致，造成錯誤的文件版本號沒有在 build 時被檢查出來，從而在應(yīng)用運行的時候才發(fā)現(xiàn)，大大增加了問題的排查難度。

為什么一定要在運行時檢查程序集文件的版本號而且在版本號出現(xiàn)問題時讓整個應(yīng)用都無法啟動？反正就這一個文件，寫個告警日志，繼續(xù)用這個文件就是了，如果無法使用這個文件，再讓整個應(yīng)用掛掉也不遲，這個地方有點想不通。

今天的發(fā)現(xiàn)也讓之前的另外一個疑問有了答案，之前在 .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 文件中，如果不能修改程序集文件的版本號，應(yīng)該可以通過修改?.deps.json 文件中 runtime 配置的?fileVersion 值來實現(xiàn)。

"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社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結(jié)

以上是生活随笔為你收集整理的dotnet pack 打包文件版本号引起 Could not load file or assembly 问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。