你好，我的作業環境是 VisualStudio 2010 & C#
我設計三個類別，分別為 A,B,C 並各自在不同的專案，但是在同一個方案中。
這三個類別的命名空間分別是：AS、BS、CS
我的想法是，A是最底層的類別，可以讓 B 去繼承；B類別可以讓 C 去繼承。
A 類別裡的方法、屬性都是宣告成 public，讓子類別、孫類別或是外部專案都可以繼承。
B 類別中有覆寫 A 類別中的一些方法。
C類別的專案有加入 B 專案的參考，也可以正常的繼承B類別，並使用或覆寫 B類別中的方法。
但是當我在建置整個方案或是編譯 C類別的專案的時候，在 C 類別的專案卻會出現以下這個錯誤。
如果我在 C類別的專案中除了加入 B 專案的參考之外，再加入 A 專案的參考，就沒有以上說的錯誤情況。
我的想法是，當日後系統大了，會有更多的基底類別，甚至可能會繼承非常多代的子類別。
依照以上說的必須引用所有父類別或是祖先類別的專案檔的話，日後維護起來會非常辛苦而且容易出錯。
是否有辦法讓 C 類別的專案參考 B 類別的專案就可以使用到 A 類別的型別或方法。
理論上都是繼承，照理說應當可以才對，但是卻發生只要孫類別的專案檔沒參考祖先類別，就無法使用祖先類別的型別或方法及屬性。
感謝回覆。
已邀請的邦友 {{ invite_list.length }}/5
arthur1977提到：
我的想法是，當日後系統大了，會有更多的基底類別，甚至可能會繼承非常多代的子類別。
有夢最美
當日後系統大了,
這就被推翻了,
當時這時看法一定又有一番新看法
尤其是這些 home ground system
arthur1977提到：
我的想法是，當日後系統大了，會有更多的基底類別，甚至可能會繼承非常多代的子類別。
依照以上說的必須引用所有父類別或是祖先類別的專案檔的話，日後維護起來會非常辛苦而且容易出錯。
沒錯！就是因為當初C++複雜的繼承關係會有很多維護上的問題，所以在JAVA就有了介面(Interface)這回事！.NET Framework這部份觀念是與JAVA相同的，繼承部份不要搞的太複雜，不然第一個被搞死的絕對是維護人員。
以您的目前覆寫來覆寫去的架構來看，我會建議是不是考慮一下Interface的作法，不要讓日後維護的人太辛苦。
iThome鐵人賽
看影片追技術