0

But not within its own assembly. Is this possible or meaningful without using abstract(even this doesn't let usage within assembly) keyword on base class?

This gives error:

internal Foo<T>{}       // trying to stop this being directly used
public Bar:Foo<float>{} // inconsistent visibility, need this to be served

this too:

public sealed Foo<T>{}
public Bar:Foo<float>{} // cannot derive from sealed class

making base class protected/private also doesn't help.

It could have been an interface but I want the base code written only once(interface forces all classes that implemented it to duplicate code), base class has only 1 virtual method and implements 2 interfaces and non-duplicated methods consists %90 of its body.

I want base class be non-usable just like interface(but usable in its own library assembly) but also have many methods and properties defined only once and also implement some other interfaces and have a virtual method but not any abstract method.

Does keyword abstract have any side-effect like bugging a type-checking code to give true instead of false, or making some optimizations of compiler impossible or having incompatibilities between very new or very old versions of C#.Net ?

While I can use it in its assembly(library), protecting it from other libraries is impossible?

huseyin tugrul buyukisik
  • 11,469
  • 4
  • 45
  • 97
  • 1
    This is a well-understood scenario and often discussed. Your post doesn't show any sign of your researching the issue. The marked duplicate addresses the various aspects of the scenario and possible work-arounds. Your comments above are unclear. You write _"I want the base code written only once(interface forces all classes that implemented it to duplicate code)"_, but making it an interface doesn't require duplicating code. It just means that what's exposed publicly is the interface, not the base or derived classes. – Peter Duniho Mar 23 '17 at 21:03
  • Note also that even if you got this to work, unless you marked `Bar` as sealed, client code can inherit _that_ and thus indirectly inherit the class you didn't want them to. Personally, I eschew `internal` -- use of that often hides broader design failures -- but I don't see the problem with the type itself being public, if you mark as internal the parts of it you don't want being public (for whatever reason...your question is also unclear on that point). – Peter Duniho Mar 23 '17 at 21:03
  • @PeterDuniho You are right. I should have read the auto-searching title recommendations better. I will search much more next time, before asking. Thank you. – huseyin tugrul buyukisik Mar 23 '17 at 21:51

0 Answers0