Export-Schnittstellen

Question

Ich habe eine Schnittstelle, die eine Eigenschaft einer anderen Schnittstelle hat. Gibt es trotzdem, die untergeordnete Schnittstelle zu exportieren/bereitzustellen/einzuschließen, wenn die übergeordnete Schnittstelle in einer Verwendung referenziert wird.

//IBar.cs 
namespace bar 
{ 
    interface IBar 
    { 
     public int BarProp { get; set; } 
    } 
} 

//IFoo.cs 
namespace foo 
{ 
    using bar 
    interface IFoo 
    { 
     public IBar FooProp { get; set; } 
    } 
} 

//elsewhere.cs 
namespace foo 
{ 
    //using bar //without this, 
    IFoo myFoo = new SomeClassThatImplementsIFoo(); 
    myFoo.FooProp.BarProp //<-- BarProp is inaccessable here 
} 

In elsewhere.cs habe ich einen Verweis auf IFoo, sondern möchte in der Lage sein, Elemente von IBar zuzugreifen, ohne Referenzen und eine using-Anweisung zu IBar schließen zu müssen. Gibt es überhaupt eine Einrichtung von IFoo, so dass es, wenn es referenziert wird, auch IBar mitbringt? So etwas wie die Art #include s in geraden C. Wenn Sie sagen "Kopieren und Einfügen von IBar in IFoo.cs", werde ich dich ignorieren.

Ich vermute, dass, da ich noch nie etwas gesehen habe, das das tun kann, die Antwort wahrscheinlich ist, dass Sie das in C# nicht tun können.

EDIT: Die Dateien IBar.cs und IFoo.cs sind in separaten Baugruppen
EDIT: Die Schnittstellen sind öffentlich, nicht die Eigenschaften

Answer 1

Ihr oben angegebener Code sollte ohne Änderungen oder zusätzliche "using" -Anweisungen funktionieren. Dies liegt daran, dass der C# -Compiler das gesamte Projekt (d. H. Alle Quelldateien) als eine große Einheit kompiliert, während C (und C++) -Compiler von Präprozessordirektiven angewiesen werden (wie #include), um ihnen mitzuteilen, welche Dateien eingeschlossen werden sollen.

Übrigens, Mitglieder in Schnittstellendeklarationen sind implizit öffentlich, daher sind Ihre 'öffentlichen' Modifier im geringsten redundant (ich denke, es gibt Ihnen auch einen Compilerfehler). Vielleicht verwirrt Sie das?

Unzugänglichkeit kann nur auftreten (im Fall von Schnittstellen), wenn Sie die Sichtbarkeitsmodifizierer nicht übereinstimmen, zum Beispiel:

internal interface IFoo 
{ 
    void Stuff(); 
} 

public interface ISomething 
{ 
    IFoo GetFoo(); 
} 

In diesem Fall, dass Sie einen Compiler-Fehler von „Uneinheitliche Zugänglichkeit“ bekommen.

Bearbeiten: Wenn woanders.cs und IBar.cs in verschiedenen Baugruppen sind, muss die Assembly mit woanders.cs darin einen Verweis auf die Baugruppe enthalten, die IBar (und IFoo) enthält. Es gibt keine Möglichkeit, dies zu automatisieren, obwohl Visual Studio Sie warnt, wenn Ihnen Referenzen fehlen (und Ihr Projekt wird nicht kompiliert).

Answer 2

namespace bar 
{ 
    interface IBar 
    { 
     public int BarProp { get; set; } 
    } 
} 

//IFoo.cs 
namespace foo 
{ 
    using bar; 
    interface IFoo 
    { 
     public IBar FooProp { get; set; } 
    } 
} 

//elsewhere.cs 
namespace foo 
{ 

    class test: IFoo { 

     public test(){ 
    //using bar //without this, 
    IFoo myFoo = new test(); 
    int val = myFoo.FooProp.BarProp; //<-- **BarProp is not inaccessable here** 
     } 
    } 
} 

Typen lassen sich über einen Namensraum nicht Dateien.

Answer 3

Dies ist keine Frage von "kann" oder "kann nicht" in C#, es ist nur die Art, wie der Cookie zerbröckelt und es ist nichts falsch daran. Im Grunde genommen haben Sie nur , um diese Assembly zu referenzieren und diesen Namespace in using Klauseln zu setzen, um auf IBar zuzugreifen.

Was macht Sie besonders problematisch? Wenn Ihr Problem nur die Bearbeitungserfahrung ist, sollten Sie ein Werkzeug wie ReSharper verwenden.

Answer 4

Nein, was Sie fragen, kann nicht in C# getan werden. Sie müssen einfach beide Anweisungen hinzufügen.

Der nächste Mechanismus zu dem, was man sich wünschen kann, und ich erwarte immer noch nicht, zu arbeiten, ist ein „mit Alias“, die wie folgt aussieht:

using BarProp = bar.IBar.BarProp; //nice try, but not legal 

Wunschdenken, aber nein.