4

I have 3 assemblies written in C#, namely A.exe, B.dll, C.dll

  • C.dll defines a public interface IfaceC.
  • A.exe defines a public class ClassA : IfaceC
  • B.dll uses ClassA but does not make explicit use of IfaceC

My question: is it possible to compile B without referencing C.dll ? I do not use it and I want to prevent a developer from using it (i.e. typing "IfaceC" in the B's code accidentally). However A.exe still needs it.

EDIT

Given my archi, A can reference C but not B, C cannot reference nor A neither B, B can reference A but not (if possible) C

coffee_machine
  • 1,203
  • 14
  • 28
  • 1
    Yes I tried. The compiler says I have to reference it. I was wondering if there is another way to do it – coffee_machine Oct 04 '11 at 11:02
  • 5
    Make ClassA implement a seperate/new interface in A.exe which B.dll can reference, such that B doesn't know anything about concrete ClassA or the C.dll interface it implements... – MattDavey Oct 04 '11 at 11:08
  • @MattDavey: I think Matt is right on the money for this particular scenario (better than my own answer). Perhaps make it an answer? – sehe Oct 04 '11 at 11:10
  • What is original intent of this question ? Basically one approach is for A to still reference C, but just add extra protection so noone except allowed assemblies will be to load C. Can be made even as run-time check - A runs C.SetLicense("I'm authorized, please let me pass."); B does not perform that call and C will throw exception because of this. – TarmoPikaro Oct 26 '20 at 15:38
  • I understand @coffee_machine's frustration here. An interface is supposed to decouple types, but client and consumer types must be tightly linked to make use of each other's interfaces. I would have thought that the Interface contract could be reduced to text matches, in the way a SQL query will work across tables with the same column names, but any reference to classes would need to go back to a strict type match. – Shane Aug 22 '22 at 00:13

2 Answers2

4

No. You need to have a reference to any assemblies containing base types or interfaces implemented by any types you use.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • If this is true, that would be really bad for my plugin architecture. It would mean that I have to update every plugin for having added an implementation of an interface that no plugin uses :( – coffee_machine Oct 04 '11 at 11:12
  • 2
    @coffee_machine: have you missed MattDavey's comment? It is both simple and effective. I would even consider the implementing classes an implementation detail that should never be exposed in a plugin interface. – sehe Oct 04 '11 at 11:35
  • Yup, I agree with that suggestion. If you don't want a client to know some details of a type, don't expose that type if you can help it. – Jon Skeet Oct 04 '11 at 12:06
0

The only other way evades your question and involves Duck Typing.

C#'s dynamic type keyword is very handy in this respect. It has the drawback of no longer having static type checking during compilation.

In effect, using dynamic you can pass in any object of (unknown) type, much like you pass object instances. The compiler let's you use the object by calling methods/properties and whatnot, as if the type was known.

Code will be emitted that looks up the relevant properties at runtime. This means that at runtime the metadata will be consulted (and the common assembly is still being loaded). The net gain is only that the 'third' assembly is not referenced, and need not be present at compilation or program loading time.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Can you explain how that would help in this case? – Ray Oct 04 '11 at 11:06
  • I suspect `dynamic` won't solve the problem. You still need to assign the dynamic variable to an object of ClassA - and you can't create it without referencing C.dll – Zasz Oct 04 '11 at 11:19
  • The point is that you might not need to assign it to a ClassA variable. Iff that is the case, then, of course, all bets are off. I still think MattDavey has contributed the best idea, but I can hardly go and take credit for that, now can I? – sehe Oct 04 '11 at 11:32
  • thanks @sehe :) Jon's answer of "no" is technically correct for the question *"is it possible to compile B without referencing C.dll?"* – MattDavey Oct 06 '11 at 08:09
  • @MattDavey: I know. I'm not saying otherwise. I think you _contributed the best idea_ in terms of real life problem solving potential. Of course having the facts is a first requirement, as always – sehe Oct 06 '11 at 08:18