[c#] Per constructor andere references nodig?

[BasieP]

Heren (sorry dames),

Ik zit met een nieuwe rariteit.
Ik heb een solution die bestaat uit 4 projecten.

project A (webapp)
project B (logische laag)
project C (dataaccess laag)
project D (framework)

Mijn project D heeft geen afhankelijkheden
Project C heeft alleen afhankelijkheid naar D
Project B naar C en D
Project A naar B en D.

Het idee is dus dat project A niet direct naar de dataaccess laag gaat, maar dit via de logische laag doet.

---

Nu heb ik in project A een call naar een constructor van een class in project B. Van deze constructor zijn een aantal varianten.
Eén ervan doet niets, een ander maakt weer een instantie aan van een class in project C. (soort abstractie dus)

Echter nu is het zo dat mijn visual studio graag wil dat ik in mijn project A een referentie naar project C leg.

De melding is iets in de trant van:

The type 'projectC_class' is defined in an assembly that is not refferenced. Please add a reference ... 

Het meest bizarre is dat wanneer ik in project A de constructor aanroep van project B die weer een instantie maakt van een class uit project C hij NIET zeurt, maar als ik de lege constructor aanroep dat hij WEL een foutmelding geeft.
Als dit al verschil zou mogen maken, zou ik het andersom verwachten.


Komt dit bij iemand bekend voor? ben ik te vaag? ik kan wat voorbeeldcode posten, maar ik denk dat het daar alleen onduidelijker van wordt.

[BasieP]

mm ik ben er inmiddels achter.

Ik had 4 constructors in mijn project B.
de derde ervan had als parameter een object uit project C.
Wanneer ik in ProjectA de eerste constructor aanriep ging het goed, wanneer ik de tweede aanriep ging het fout (beide hebben alleen basic type parameters)

Toen ik de derde constructor internal heb gemaakt ging het ook goed

Die hele derde constructor gebruikte ik niet, maar blijkbaar doet die compiler ook iets niet helemaal goed...

[Kaw]

De compiler van C# doet een volledige check op dat soort dingen. Dat is me al vaker opgevallen en in sommige gevallen niet zo handig. Maar als je in een groot team werkt, dan ben je blij dat de compiler hier zo strikt me om gaat. Stel je voor dat bepaalde functies niet bedoeld zijn om vanuit bepaalde libraries aan te spreken en degene die het weet doet dit ook niet. Jij komt als teamlid wel aan de verboden vruchten en je zit ineens met compile-errors. Dan is het knap lastig om te achterhalen waarom wat is gedaan.

.Net heeft hiervoor niet voor niets de OO-principles aangehouden. Denk altijd goed na wat public, internal, protected of private zou moeten zijn. Dat scheelt problemen in een later stadium.