.NET 7 AOT 的使用以及 .NET 與 Go 互相呼叫

2022-11-10 12:01:52

背景

其實,規劃這篇文章有一段時間了,但是比較懶,所以一直拖著沒寫。

最近時總更新太快了,太捲了,所以藉著 .NET 7 正式版釋出,熬夜寫完這篇文章,希望能夠追上時總的一點距離。

本文主要介紹如何在 .NET 和 Go 語言中如何生成系統(Windows)動態連結庫,又如何從程式碼中參照這些庫中的函數。

在 .NET 部分,介紹如何使用 AOT、減少二進位制檔案大小、使用最新的 [LibraryImport] 匯入庫函數;

在 Go 語言部分,介紹如何使用 GCC 編譯 Go 程式碼、如何通過 syscall 匯入庫函數。

在文章中會演示 .NET 和 Go 相互呼叫各自生成的動態連結庫,以及對比兩者之間的差異。

本文文章內容以及原始碼,可以 https://github.com/whuanle/csharp_aot_golang 中找到,如果本文可以給你帶來幫助,可以到 Github 點個星星嘛。

C# 部分

環境要求

SDK:.NET 7 SDKDesktop development with C++ workload

IDE:Visual Studio 2022

Desktop development with C++ workload 是一個工具集,裡面包含 C++ 開發工具,需要在 Visual Studio Installer 中安裝,如下圖紅框中所示。

建立一個控制檯專案

首先建立一個 .NET 7 控制檯專案,名稱為 CsharpAot

開啟專案之後,基本程式碼如圖所示:

我們使用下面的程式碼做測試:

public class Program
{
    static void Main()
    {
        Console.WriteLine("C# Aot!");
        Console.ReadKey();
    }
}

體驗 AOT 編譯

這一步,可以參考官方網站的更多說明:

https://learn.microsoft.com/zh-cn/dotnet/core/deploying/native-aot/

為了能夠讓專案發布時使用 AOT 模式,需要在專案檔案中加上 <PublishAot>true</PublishAot> 選項。

然後使用 Visual Studio 釋出專案。

釋出專案的組態檔設定,需要按照下圖進行設定。

AOT 跟 生成單個檔案 兩個選項不能同時使用,因為 AOT 本身就是單個檔案。

設定完成後,點選 釋出,然後開啟 Release 目錄,會看到如圖所示的檔案。

.exe 是獨立的可執行檔案,不需要再依賴 .NET Runtime 環境,這個程式可以放到其他沒有安裝 .NET 環境的機器中執行。

然後刪除以下三個檔案:

    CsharpAot.exp
    CsharpAot.lib
    CsharpAot.pdb

光用 .exe 即可執行,其他是偵錯符號等檔案,不是必需的。

剩下 CsharpAot.exe 檔案後,啟動這個程式:

C# 呼叫庫函數

這一部分的程式碼範例,是從筆者的一個開源專案中抽取出來的,這個專案封裝了一些獲取系統資源的介面,以及快速接入 Prometheus 監控。

不過很久沒有更新了,最近沒啥動力更新,讀者可以點選這裡瞭解一下這個專案:

https://github.com/whuanle/CZGL.SystemInfo/tree/net6.0/src/CZGL.SystemInfo/Memory

因為後續程式碼需要,所以現在請開啟 「允許不安全程式碼」。

本小節的範例是通過使用 kernel32.dll 去呼叫 Windows 的核心 API(Win32 API),呼叫 GlobalMemoryStatusEx 函數 檢索有關係統當前使用實體記憶體和虛擬記憶體的資訊

使用到的 Win32 函數可參考:https://learn.microsoft.com/zh-cn/windows/win32/api/sysinfoapi/nf-sysinfoapi-globalmemorystatusex

關於 .NET 呼叫動態連結庫的方式,在 .NET 7 之前,通過這樣呼叫:

    [DllImport("Kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static extern Boolean GlobalMemoryStatusEx(ref MemoryStatusExE lpBuffer);

在 .NET 7 中,出現了新的操作方式 [LibraryImport]

檔案是這樣介紹的:

Indicates that a source generator should create a function for marshalling arguments instead of relying on the runtime to generate an equivalent marshalling function at run time.

指示源生成器應建立用於編組引數的函數,而不是依賴執行庫在執行時生成等效的編組函數。

簡單來說,就是我們要使用 AOT 寫程式碼,然後程式碼中參照到別的動態連結庫時,需要使用 [LibraryImport] 引入這些函數。

筆者沒有在 AOT 下測試過 [DllImport],讀者感興趣可以試試。

新建兩個結構體 MEMORYSTATUS.csMemoryStatusExE.cs

MEMORYSTATUS.cs

public struct MEMORYSTATUS
{
    internal UInt32 dwLength;
    internal UInt32 dwMemoryLoad;
    internal UInt32 dwTotalPhys;
    internal UInt32 dwAvailPhys;
    internal UInt32 dwTotalPageFile;
    internal UInt32 dwAvailPageFile;
    internal UInt32 dwTotalVirtual;
    internal UInt32 dwAvailVirtual;
}

MemoryStatusExE.cs

public struct MemoryStatusExE
{
    /// <summary>
    /// 結構的大小,以位元組為單位,必須在呼叫 GlobalMemoryStatusEx 之前設定此成員,可以用 Init 方法提前處理
    /// </summary>
    /// <remarks>應當使用本物件提供的 Init ,而不是使用建構函式!</remarks>
    internal UInt32 dwLength;

    /// <summary>
    /// 一個介於 0 和 100 之間的數位,用於指定正在使用的實體記憶體的大致百分比(0 表示沒有記憶體使用,100 表示記憶體已滿)。
    /// </summary>
    internal UInt32 dwMemoryLoad;

    /// <summary>
    /// 實際實體記憶體量,以位元組為單位
    /// </summary>
    internal UInt64 ullTotalPhys;

    /// <summary>
    /// 當前可用的實體記憶體量,以位元組為單位。這是可以立即重用而無需先將其內容寫入磁碟的實體記憶體量。它是備用列表、空閒列表和零列表的大小之和
    /// </summary>
    internal UInt64 ullAvailPhys;

    /// <summary>
    /// 系統或當前程序的當前已提交記憶體限制,以位元組為單位,以較小者為準。要獲得系統範圍的承諾記憶體限制,請呼叫GetPerformanceInfo
    /// </summary>
    internal UInt64 ullTotalPageFile;

    /// <summary>
    /// 當前程序可以提交的最大記憶體量,以位元組為單位。該值等於或小於系統範圍的可用提交值。要計算整個系統的可承諾值,呼叫GetPerformanceInfo核減價值CommitTotal從價值CommitLimit
    /// </summary>

    internal UInt64 ullAvailPageFile;

    /// <summary>
    /// 呼叫程序的虛擬地址空間的使用者模式部分的大小,以位元組為單位。該值取決於程序型別、處理器型別和作業系統的設定。例如,對於 x86 處理器上的大多數 32 位程序,此值約為 2 GB,對於在啟用4 GB 調整的系統上執行的具有大地址感知能力的 32 位程序約為 3 GB 。
    /// </summary>

    internal UInt64 ullTotalVirtual;

    /// <summary>
    /// 當前在呼叫程序的虛擬地址空間的使用者模式部分中未保留和未提交的記憶體量,以位元組為單位
    /// </summary>
    internal UInt64 ullAvailVirtual;


    /// <summary>
    /// 預訂的。該值始終為 0
    /// </summary>
    internal UInt64 ullAvailExtendedVirtual;

    internal void Refresh()
    {
        dwLength = checked((UInt32)Marshal.SizeOf(typeof(MemoryStatusExE)));
    }
}

定義參照庫函數的入口:

public static partial class Native
{

    /// <summary>
    /// 檢索有關係統當前使用物理和虛擬記憶體的資訊
    /// </summary>
    /// <param name="lpBuffer"></param>
    /// <returns></returns>
    [LibraryImport("Kernel32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static partial Boolean GlobalMemoryStatusEx(ref MemoryStatusExE lpBuffer);
}

然後呼叫 Kernel32.dll 中的函數:

public class Program
{
    static void Main()
    {
        var result = GetValue();
        Console.WriteLine($"當前實際可用記憶體量:{result.ullAvailPhys / 1000 / 1000}MB");
        Console.ReadKey();
    }
    
    /// <exception cref="Win32Exception"></exception>
    public static MemoryStatusExE GetValue()
    {
        var memoryStatusEx = new MemoryStatusExE();
        // 重新初始化結構的大小
        memoryStatusEx.Refresh();
        // 重新整理值
        if (!Native.GlobalMemoryStatusEx(ref memoryStatusEx)) throw new Win32Exception("無法獲得記憶體資訊");
        return memoryStatusEx;
    }
}

使用 AOT 釋出專案,執行 CsharpAot.exe 檔案。

減少體積

在前面兩個例子中可以看到 CsharpAot.exe 檔案大約在 3MB 左右,但是這個檔案還是太大了,那麼我們如何進一步減少 AOT 檔案的大小呢?

讀者可以從這裡瞭解如何裁剪程式:https://learn.microsoft.com/zh-cn/dotnet/core/deploying/trimming/trim-self-contained

需要注意的是,裁剪是沒有那麼簡單的,裡面設定繁多,有一些選項不能同時使用,每個選項又能帶來什麼樣的效果,這些選項可能會讓開發者用得很迷茫。

經過筆者的大量測試,筆者選用了以下一些設定,能夠達到很好的裁剪效果,供讀者測試。

首先,引入一個庫:

	<ItemGroup>
		<PackageReference Include="Microsoft.DotNet.ILCompiler" Version="7.0.0-*" />
	</ItemGroup>

接著,在專案檔案中加入以下選項:

		<!--AOT 相關-->
		<PublishAot>true</PublishAot>	
		<TrimMode>full</TrimMode>
		<RunAOTCompilation>True</RunAOTCompilation>
		<PublishTrimmed>true</PublishTrimmed>
		<TrimmerRemoveSymbols>true</TrimmerRemoveSymbols>
		<PublishReadyToRunEmitSymbols>false</PublishReadyToRunEmitSymbols>
		<DebuggerSupport>false</DebuggerSupport>
		<EnableUnsafeUTF7Encoding>true</EnableUnsafeUTF7Encoding>
		<InvariantGlobalization>true</InvariantGlobalization>
		<HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>
		<MetadataUpdaterSupport>true</MetadataUpdaterSupport>
		<UseSystemResourceKeys>true</UseSystemResourceKeys>
		<IlcDisableReflection >true</IlcDisableReflection>

最後,釋出專案。

吃驚!生成的可執行檔案只有 1MB 了,而且還可以正常執行。

筆者注:雖然現在看起來 AOT 的檔案很小了,但是如果使用到 HttpClientSystem.Text.Json 等庫,哪怕只用到了一兩個函數,最終包含這些庫以及這些庫使用到的依賴,生成的 AOT 檔案會大得驚人。

所以,如果專案中使用到其他 nuget 包的時候,別想著生成的 AOT 能小多少!

C# 匯出函數

這一步可以從時總的部落格中學習更多:https://www.cnblogs.com/InCerry/p/CSharp-Dll-Export.html

PS:時總真的太強了。

然後通過以下命令釋出專案,生成連結庫:

 dotnet publish -p:NativeLib=Shared -r win-x64 -c Release

看起來還是比較大,為了繼續裁剪體積,我們可以在 CsharpExport.csproj 中加入以下設定,以便生成更小的可執行檔案。

		<!--AOT 相關-->
		<PublishAot>true</PublishAot>
		<TrimMode>full</TrimMode>
		<RunAOTCompilation>True</RunAOTCompilation>
		<PublishTrimmed>true</PublishTrimmed>
		<TrimmerRemoveSymbols>true</TrimmerRemoveSymbols>
		<PublishReadyToRunEmitSymbols>false</PublishReadyToRunEmitSymbols>
		<DebuggerSupport>false</DebuggerSupport>
		<EnableUnsafeUTF7Encoding>true</EnableUnsafeUTF7Encoding>
		<InvariantGlobalization>true</InvariantGlobalization>
		<HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>
		<MetadataUpdaterSupport>true</MetadataUpdaterSupport>
		<UseSystemResourceKeys>true</UseSystemResourceKeys>
		<IlcDisableReflection >true</IlcDisableReflection>

C# 呼叫 C# 生成的 AOT

在本小節中,將使用 CsharpAot 專案呼叫 CsharpExport 生成的動態連結庫。

CsharpExport.dll 複製到 CsharpAot 專案中,並設定 始終複製

CsharpAotNative 中加上:

    [LibraryImport("CsharpExport.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.I4)]
    internal static partial Int32 Add(Int32 a, Int32 b);

然後在程式碼中使用:

    static void Main()
    {
        var result = Native.Add(1, 2);
        Console.WriteLine($"1 + 2 = {result}");
        Console.ReadKey();
    }

在 Visual Studio 裡啟動 Debug 偵錯:

可以看到,是正常執行的。

接著,將 CsharpAot 專案發布為 AOT 後,再次執行:

可以看到,.NET AOT 呼叫 .NET AOT 的程式碼是沒有問題的。

Golang 部分

Go 生成 Windows 動態連結庫,需要安裝 GCC,通過 GCC 編譯程式碼生成對應平臺的檔案。

安裝 GCC

需要安裝 GCC 10.3,如果 GCC 版本太新,會導致編譯 Go 程式碼失敗。

開啟 tdm-gcc 官網,通過此工具安裝 GCC,官網地址:

https://jmeubank.github.io/tdm-gcc/download/

下載後,根據提示安裝。

然後新增環境變數:

D:\TDM-GCC-64\bin

執行 gcc -v,檢查是否安裝成功,以及版本是否正確。

Golang 匯出函數

本節的知識點是 cgo,讀者可以從這裡瞭解更多:

https://www.programmerall.com/article/11511112290/

新建一個 Go 專案:

新建一個 main.go 檔案,檔案內容如下:

package main

import (
	"fmt"
)
import "C"

//export Start
func Start(arg string) {
	fmt.Println(arg)
}

// 沒用處
func main() {
}

在 Golang 中,要匯出此檔案中的函數,需要加上 import "C",並且 import "C" 需要使用獨立一行放置。

//export {函數名稱} 表示要匯出的函數,注意,//export 之間 沒有空格。

main.go 編譯為動態連結庫:

go build -ldflags "-s -w" -o main.dll -buildmode=c-shared main.go

不得不說,Go 編譯出的檔案,確實比 .NET AOT 小一些。

前面,筆者演示了 .NET AOT 呼叫 .NET AOT ,那麼, Go 呼叫 Go 是否可以呢?

答案是:不可以。

因為 Go 編譯出來的 動態連結庫本身帶有 runtime,Go 呼叫 main.dll 時 ,會出現異常。

具有情況可以通過 Go 官方倉庫的 Issue 瞭解:https://github.com/golang/go/issues/22192

這個時候,.NET 加 1 分。

雖然 Go 不能呼叫 Go 的,但是 Go 可以呼叫 .NET 的。在文章後面會介紹。

雖然說 Go 不能呼叫自己,這裡還是繼續補全程式碼,進一步演示一下。

Go 通過動態連結庫呼叫函數的範例:

func main() {
	maindll := syscall.NewLazyDLL("main.dll")
	start := maindll.NewProc("Start")

	var v string = "測試程式碼"
	var ptr uintptr = uintptr(unsafe.Pointer(&v))
	start.Call(ptr)
}

程式碼執行後會報錯:

.NET C# 和 Golang 互調

C# 呼叫 Golang

main.dll 檔案複製放到 CsharpAot 專案中,設定 始終複製

然後在 Native 中新增以下程式碼:

    [LibraryImport("main.dll", SetLastError = true)]
    internal static partial void Start(IntPtr arg);

呼叫 main.dll 中的函數:

    static void Main()
    {
        string arg = "讓 Go 跑起來";
        // 將申請非託管記憶體string轉換為指標
        IntPtr concatPointer = Marshal.StringToHGlobalAnsi(arg);
        Native.Start(concatPointer);
        Console.ReadKey();
    }

在 .NET 中 string 是參照型別,而在 Go 語言中 string 是值型別,這個程式碼執行後,會出現什麼結果呢?

執行結果是輸出一個長數位。

筆者不太瞭解 Golang 內部的原理,不確定這個數位是不是 .NET string 傳遞了指標地址,然後 Go 把指標地址當字串列印出來了。

因為在 C、Go、.NET 等語言中,關於 char、string 的內部處理方式不一樣,因此這裡的傳遞方式導致了跟我們的預期結果不一樣。

接著,我們將 main.go 檔案的 Start 函數改成:

//export Start
func Start(a,b int) int{
	return a+b
}

然後執行命令重新生成動態連結庫:

go build -ldflags "-s -w" -o main.dll -buildmode=c-shared main.go

main.dll 檔案 複製到 CsharpAot 專案中,將 Start 函數參照改成:

    [LibraryImport("main.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.I4)]
    internal static partial Int32 Start(int a, int b);

執行程式碼呼叫 Start 函數:

    static void Main()
    {
        var result = Native.Start(1, 2);
        Console.WriteLine($"1 + 2 = {result}");
        Console.ReadKey();
    }

Golang 呼叫 C#

CsharpExport.dll 檔案複製放到 Go 專案中。

main 的程式碼改成:

func main() {
	maindll := syscall.NewLazyDLL("CsharpExport.dll")
	start := maindll.NewProc("Add")

	var a uintptr = uintptr(1)
	var b uintptr = uintptr(2)
	result, _, _ := start.Call(a, b)

	fmt.Println(result)
}

將引數改成 19,再次執行:

其他

在本文中,筆者演示了 .NET AOT,雖然簡單的範例看起來是正常的,體積也足夠小,但是如果加入了實際業務中需要的程式碼,最終生成的 AOT 檔案也是很大的。

例如,專案中使用 HttpClient 這個庫,會發現裡面加入了大量的依賴檔案,導致生成的 AOT 檔案很大。

在 .NET 的庫中,很多時候設計了大量的過載,同一個程式碼有好幾個變種方式,以及函數的呼叫鏈太長,這樣會讓生成的 AOT 檔案變得比較臃腫。

目前來說, ASP.NET Core 還不支援 AOT,這也是一個問題。

在 C# 部分,演示瞭如何使用 C# 呼叫系統介面,這裡讀者可以瞭解一下 pinvokehttp://pinvoke.net/

這個庫封裝好了系統介面,開發者不需要自己擼一遍,通過這個庫可以很輕鬆地呼叫系統介面,例如筆者最近在寫 MAUI 專案,通過 Win32 API 控制桌面視窗,裡面就使用到 pinvoke 簡化了大量程式碼。

本文是筆者熬夜寫的,比較趕,限於水平,文中可能會有錯誤的地方,望大佬不吝指教。