Zamówienie konstruktora VB.Net?

Question

Dlaczego ZAMÓWIENIE konstruktora ma znaczenie w VB.Net? Buduję bibliotekę typu .Net, która ma całkowicie owijać bibliotekę COM, tak aby konsumenci API mogli udawać, że używają ładnej biblioteki .Net z kolekcjami .Net i cokolwiek, zamiast biblioteki COM.

Obecnie większość moich zajęć to tylko 1 do 1 owijaczy zbudowanych przy użyciu Reflection i CodeDOM. Klasy te mają wewnętrzny konstruktor, który jako parametr przyjmuje bazowy typ COM. CodeDOM buduje to jako pierwszy konstruktor klasy. Używanie tych klas z C# nie stanowi problemu. Wszystko, czego potrzebuję, to odwołanie do biblioteki .Net i wszystko działa dobrze.

Problemy pojawiają się, gdy próbuję korzystać z tych klas z projektu VB.Net. Jeśli pierwszy konstruktor ma jako argument typ COM, projekt VB.Net wymaga odwołania do zespołu powiązań COM jako odwołania. Jeśli pierwszy konstruktor nie ma argumentów lub ma tylko zarządzane typy, wszystko działa dobrze. Moja biblioteka zajęć jest napisana w języku C#.

następujące utwory:

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

Poniższa wymaga odniesienia do montażu 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; 
    } 
} 

Teraz mogę rozwiązać ten problem poprzez stworzenie obojętne prywatną konstruktora do tych klas jak osoby pierwszy konstruktor, ale jestem bardziej ciekawy, co to powoduje? Dlaczego kolejność deklaracji konstruktora ma znaczenie w VB.Net?

Aktualizacja

To brzmiało tak szalony, że zacząłem wątpić w to sam. Udało mu się powielić to z 3 projektami.

biblioteki C# Klasa: Owinięty

namespace Wrapped 
{ 
    public class Class1 
    { 
    } 
} 

biblioteki C# Klasa: Wrapper

aplikacja

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

VB.Net konsoli: Referer

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

Wrapper dotyczy Owinięty Referer dotyczy Wrapper Referer NIE odnosi się do owiniętego

Dim w As New Wrapper.Class1 

Produkuje błąd

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

zamiana kolejności konstruktorów dba o błędzie.

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

Aktualizacja po zabawy kilka

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

Jeśli poprawna (nie mogę łatwo zweryfikować), który jest fasinating. Kolejność nie powinna mieć znaczenia, AFAIK. Jeśli jesteś tego pewien, to prawdopodobnie log as a bug on connect (z przykładowym kodem).

Answer 2

Nie, kolejność konstruktorów, ponieważ są one wymienione w kodzie (przy użyciu C# lub VB.NET) nie ma znaczenia.

Jednak w tym konkretnym przypadku (nie przetestowałem tego) prawdopodobnie znalazłeś błąd. Zanim przejdziemy do wniosku "to łamie moją maszynę", możesz chcieć, aby ktoś inny zweryfikował problem na swoim komputerze, abyś wiedział, że to nie tylko Twoja maszyna. Miałem to już wcześniej.

Answer 3

Confirmed as a bug. Zbyt trudne do naprawienia, aby było warto, więc myślę, że po prostu z tym żyć. Na szczęście wydaje się wymagać projektów w różnych językach, w których pojawiają się nietypowe konfiguracje klas.