0

In c# version 8 (or higher) we're able to create internal member in interfaces. For example, I have project A that have interface IRunnable with internal void:

public interface IRunnable
{
    internal void DoSomeInternalStuff();
}

Now, I have Student class in project A that implements IRunnable:

public class Student : IRunnable
{
    void IRunnable.DoSomeInternalStuff()
    {
        //Do stuff
    }
}

Everything is working. But now, I created project B and created class Teacher. Now I want to implement IRunnable:

public class Teacher : IRunnable
{
    void IRunnable.DoSomeInternalStuff()
    {
        //Do stuff
    }
}

The compiler is giving me an error:

IRunnable.DoSomeInternalStuff()' is inaccessible due to its protection

How to deal with this? How can I implement that interface on project B?

Dilshod K
  • 2,924
  • 1
  • 13
  • 46
  • 1
    you'll need to change the `internal` to `public` – jazb Feb 10 '22 at 05:37
  • Side note: while duplicate will solve your problem, please try to reconsider your design - saying that interface is public but has non-accessible member is somewhat strange. Maybe you should make interface `internal` too (also you seem to be against that being internal altogether with current requirements) – Alexei Levenkov Feb 10 '22 at 05:56
  • @AlexeiLevenkov I agree, it looks strange. In my use case project, A is a framework for third-party devs and I don't want to make public some methods for third-party devs' projects. My project B is an extension of project A, so it is OK, when some internal properties are visible. BUT these internals should not be visible for projects of third-party devs. I enabled InternalsVisible for project B, however it doesn't looks good because when third-party dev has project with name B internals will be visible. So I want to know what is a correct way of doing it – Dilshod K Feb 10 '22 at 06:18
  • @DilshodK realistically the only reasonable option is to stop being overly smart and keep internal and public interfaces strictly separate - interface like one shown in the question is a major pain to deal with - you can't mock it which would likely be huge problem for users of "the library", looks too tempting to try to implement it,... If you want to make your life harder too (to match pain you making others feel) strongly sign your binaries - that would solve your `InternalsVisibleTo` concern. – Alexei Levenkov Feb 10 '22 at 06:29

1 Answers1

0

Unfortunately, that breaks the use of internal. As per the definition, internal restricts the use of the method to the files or assemblies it is within. This is why it won't work for you in this situation.

Edit: The question was closed as a duplicate, and the answer linked will show you how to expand the applicability of internal to other assemblies. As per Alexei's suggestion, I'll include the appropriate information here.

In Project A, you can include the InternalsVisibleTo([Name]) attribute on your assembly to enable visibility to a different assembly. For example:

[assembly: InternalsVisibleTo("ProjectB")]
namespace TestApp1
{

This will enable ProjectB to access the method marked as internal on the IRunnable.DoSomeInternalStuff() interface, as it has been expressly allowed.

Don Tickner
  • 61
  • 5