VB.Net 建構子順序很重要?
為什麼建構子 ORDER 在 VB.Net 中很重要?我正在建構一個 .Net 類型庫,它旨在完全包裝底層 COM 庫,以便 API 的使用者可以假裝使用帶有 .Net 集合的漂亮 .Net 庫以及諸如此類的東西,而不是 COM 庫。
目前我的大多數類只是使用反射和 CodeDOM 建構的 1 對 1 包裝器。這些類有一個內部建構子,它將底層的 COM 類型作為參數。CodeDOM 將 this 建構為該類的第一個建構子。在 C# 中使用這些類被證明是沒有問題的。我所需要的只是對 .Net 庫的引用,並且一切正常。
當我嘗試從 VB.Net 項目中使用這些類時,就會出現問題。如果第一個建構子將 COM 類型作為參數,則 VB.Net 項目需要 COM 互操作程序集作為引用。如果第一個建構子沒有參數或只有託管類型,則一切正常。我的類庫是用 C# 編寫的。
以下作品:
public class ObjectID { public ObjectID(int type, int id) { this.Type = type; this.ID = id; } internal ObjectID(COMLib.ObjectID id) : this(id.Type, id.ID) { } public int ID { get; set; } public int Type { get; set; } internal COMLib.ObjectID ToCOM() { COMLib.ObjectID id = new COMLib.ObjectID(); id.ID = this.ID; id.Type = this.Type; return id; } }以下需要對 COMLib.Interop 程序集的引用:
public class ObjectID { internal ObjectID(COMLib.ObjectID id) : this(id.Type, id.ID) { } public ObjectID(int type, int id) { this.Type = type; this.ID = id; } public int ID { get; set; } public int Type { get; set; } internal COMLib.ObjectID ToCOM() { COMLib.ObjectID id = new COMLib.ObjectID(); id.ID = this.ID; id.Type = this.Type; return id; } }現在我可以通過為這些類創建一個虛擬私有建構子作為第一個建構子來解決這個問題,但我更好奇是什麼原因造成的?為什麼建構子聲明的順序在 VB.Net 中很重要?
更新
這聽起來太瘋狂了,以至於我自己開始懷疑。設法用 3 個項目複製它。
C# 類庫:已包裝
namespace Wrapped { public class Class1 { } }C# 類庫:包裝器
namespace Wrapper { public class Class1 { internal Class1(Wrapped.Class1 c) { } public Class1() { } } }VB.Net 控制台應用程序:Referer
Module Module1 Sub Main() Dim w As New Wrapper.Class1 End Sub End ModuleWrapper 指 Wrapped Referer 指 Wrapper Referer 不指 Wrapped
Dim w As New Wrapper.Class1產生錯誤
Reference required to assembly 'Wrapped, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' containing the type 'Wrapped.Class1'. Add one to your project.交換建構子的順序可以解決錯誤。
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=442224
玩了幾遍後更新
Causes error: No error: Vb-ReferTest Vb-RefererTest | | Fixes error in Vb- V V RefererTest even Cs-Wrapper Cs-Wrapper Vb-Wrapper <- if the Vb-Wrapper | \ / and the RefererTest V V V have no direct Cs-WrappedLibrary Cs-WrappedLibrary relationship
如果正確(我無法輕易驗證),那真是令人著迷。順序不重要,AFAIK。如果您確定這一點,那麼可能會在連接上記錄為錯誤(使用範常式式碼)。
確認為錯誤。太難修復它也不值得,所以我想我們會忍受它。幸運的是,它似乎需要具有不常見的類設置的跨語言項目才能出現。