L'ordine del costruttore VB.Net è importante?

Question

Perché il costruttore ORDER è importante in VB.Net? Sto costruendo una libreria di tipo .Net che è pensata per racchiudere completamente una libreria COM sottostante in modo che i consumatori dell'API possano fingere di usare una bella libreria .Net con collezioni .Net e quant'altro invece di una libreria COM.

Attualmente la maggior parte delle mie classi sono solo da 1 a 1 wrapper create con Reflection e CodeDOM. Queste classi hanno un costruttore interno che prende come parametro il tipo COM sottostante. CodeDOM lo crea come primo costruttore della classe. L'utilizzo di queste classi da C# non è un problema. Tutto ciò di cui ho bisogno è un riferimento alla libreria .Net e tutto funziona bene.

I problemi si presentano quando provo a utilizzare queste classi da un progetto VB.Net. Se il primo costruttore ha un tipo COM come argomento, il progetto VB.Net richiede l'assembly di interoperabilità COM come riferimento. Se il primo costruttore non ha argomenti o ha solo i tipi gestiti tutto funziona correttamente. La mia libreria di classi è scritta in C#.

le seguenti opere:

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; 
    } 
} 

Quanto segue richiede un riferimento all'assembly 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; 
    } 
} 

Ora posso risolvere questo con la creazione di un costruttore privato fittizio a queste classi come la primo costruttore ma sono più curioso di sapere che cosa causa questo? Perché l'ordine delle dichiarazioni del costruttore è importante in VB.Net?

Aggiornamento

questo suonava così folle che ho iniziato a dubitare di me stesso. Riuscito a replicarlo con 3 progetti.

libreria C# Classe: Spostato

namespace Wrapped 
{ 
    public class Class1 
    { 
    } 
} 

libreria C# Classe: Wrapper

namespace Wrapper 
{ 
    public class Class1 
    { 
     internal Class1(Wrapped.Class1 c) { } 
     public Class1() { } 
    } 
} 

VB.Net console app: Referer

Module Module1 
    Sub Main() 
     Dim w As New Wrapper.Class1 
    End Sub 
End Module 

Wrapper si riferisce a Wrapped Referer si riferisce a Wrapper Referer NON si riferisce a Wrapped

Dim w As New Wrapper.Class1 

genera un errore

Reference required to assembly 'Wrapped, Version=1.0.0.0, 
             Culture=neutral, 
             PublicKeyToken=null' 
containing the type 'Wrapped.Class1'. 
Add one to your project. 

Scambiare l'ordine dei costruttori si occupa dell'errore.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=442224

aggiornamento dopo aver giocato in giro ancora un po '

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 

Answer 1

Se corretta (non posso facilmente verificare), che è il posto assolutamente affascinante. L'ordine non dovrebbe importare, AFAIK. Se ne sei sicuro, forse log as a bug on connect (con codice di esempio).

Answer 2

No, l'ordine dei Costruttori in cui sono elencati nel codice (utilizzando C# o VB.NET) non importa.

Tuttavia, in questo caso specifico (non ho provato) si potrebbe aver trovato un bug. Prima di saltare alla conclusione "si rompe sulla mia macchina", potresti volere che qualcun altro verifichi il problema sul loro computer, quindi sai che non è solo la tua macchina. Ho avuto questo successo prima.

Answer 3

Confirmed as a bug. Troppo difficile da risolvere perché valga la pena, quindi suppongo che vivremo con esso. Fortunatamente sembra che siano necessari progetti di linguaggio incrociato con configurazioni di classi non comuni.