C# Remoting 泛型方法多載陷阱：NullReferenceException 根因分析與規避方案

現象重現

介面定義兩個泛型多載：

public interface IComputer
{
    int Add(TEntity c);
    int Add(IList list);
}

Client 呼叫 remoteComputer.Add<GameRecordDetail>(new GameRecordDetail()) 拋出 System.NullReferenceException，堆疊指向 MethodCall.ResolveMethod。若將第二個方法改名 Add2 或移除泛型參數（改為具體型別），問題消失。

實驗矩陣與結論

結論：.NET Remoting 在解析泛型多載方法時，MethodCall.ResolveMethod 內部邏輯缺陷，導致無法正確繫結至正確的方法多載，拋出空參考異常。

根因推測

Remoting 透過二進位訊息傳遞方法呼叫（BinaryMethodCallMessage）。序列化時需將方法簽章（含泛型參數）編碼；反序列化端 ResolveMethod 依據簽章在目標型別中尋找匹配的 MethodInfo。當存在同名泛型多載且泛型參數數量相同時，反射查找邏輯可能混淆，回傳 null，後續 dereference 觸發 NRE。

規避方案

1. 重命名方法（最簡單）：AddSingle / AddList。
2. 移除泛型參數：改用具體型別簽章。
3. 改用 WCF / Web API / gRPC：Remoting 已被微軟標記為 Legacy，新專案請勿使用。

補充：若必須維護舊 Remoting 系統

• 在介面層以 [Obsolete] 標記舊多載，新增非多載版本供新代碼呼叫。
• 在 Server 端實作類別中顯式實作介面方法，避免公開多載：int IComputer.Add<T>(T c) { ... } int IComputer.Add<T>(IList<T> list) { ... }，但無法從根本解決 Proxy 端解析問題。

遷移建議

Remoting 依賴 .NET Framework 專有二進位協定，跨平台、跨語言、防火牆穿透皆受限。建議漸進式遷移至 ASP.NET Core Web API + gRPC，享受現代化序列化、契約優先、可觀測性與雲原生支援。