私はちょうど今注目している奇妙な問題に出くわしました。.Net継承 - 自動従属参照動作の問題
あなたは3つのプロジェクト
**議論の後に編集NOTE **
プロジェクトLIBAと解決策を持っている場合 - ClassBの
を持っています - にClassAnamespace LibA
{
public class ClassA
{
public override string ToString()
{
return "The logic in class A!";
}
}
}
プロジェクトLibBを持っています
using LibA;
namespace LibB
{
public class ClassB
{
public ClassA a;
public ClassB()
{
a = new ClassA();
}
public object Foo()
{
return a;
}
}
}
プロジェクトLibC - クラスCを持っています
あなたがこれをコンパイルした場合using LibB;
namespace LibC
{
public class ClassC
{
public ClassB b;
public ClassC()
{
b = new ClassB();
}
public object Foo()
{
return b.Foo();
}
}
}
最後にテストドライバー
using System;
using LibC;
namespace Shell
{
class Program
{
static void Main(string[] args)
{
ClassC c = new ClassC();
Console.WriteLine(c.Foo());
}
}
}
今、すべてが完璧に動作します。 LibCのバイナリフォルダの内容を調べると、LibAとLibBをプルする必要があるかどうかを判断するために依存関係のチェーンが自動的にロールオーバーされることがわかります。
ただし、クラスBをクラスAから継承するように変更する場合 このようコンパイルする
using LibA;
namespace LibB
{
public class ClassB : ClassA
{
ClassA a;
}
}
試みとして、あなたはエラー
エラー2型「LibA.ClassA」が参照されていないアセンブリで定義されているを取得します。アセンブリ 'LibA、Version = 1.0.0.0、Culture = neutral、PublicKeyToken = null'への参照を追加する必要があります。
**元の質問には、**
はは誰もが知っているか、なぜLIBAにClassA ClassBののメンバーを参照するのに十分なスマートです（それがMSBuildのか、Visual Studioのであるかどうか）が、それはに十分にスマートではありませんClassAがClassBの基本クラスである場合、参照LibA？
は、私はそれがnitpickyだけど、私は実際にいくつかの一貫性のある行動をお願い申し上げます
**これらの観察テストと改正質問**
私はいくつかは、「直接」または「間接的」として定義するものを聞いています参照。しかし、直接的には可視性のスコープだけではなく、継承と実際のタイプの使用のようです。
テストドライバは、LibA、LibB、およびLibCを解決して自動的に参照できるほどスマートです。
publicメンバーClassAでClassBが可視ですが、それだけではコンパイル/リンクエラーが発生しません。
デバッガは、テストドライバからClassAを確実に解決するので、正しいアセンブリがロードされていることが明らかです。
だから心に留めてください。私は今、 "直接"と "間接"のものをすべて手に入れました。
リンカ/コンパイラ/ IDEが少なくとも「直接」シナリオで参照されたライブラリの依存関係を自動的に参照しようとしないのはなぜですか？依存関係が存在することを知り、間接的なシナリオでそれらを参照することは、明らかにスマートです。
興味深い.... +1 – RPM1984
最も興味深いのは、以前のVB.NETの男として、これは私が理解できないものです。 VB.NETコンパイラは、プロジェクトの依存関係を連鎖させるほどスマートです。なぜC＃コンパイラではないのですか？ – Crono