Explicity interface visibility and Namespace Question

  • Thread starter Thread starter KK
  • Start date Start date
K

KK

Is it possible to have a interface accessible by all the projects
in my solution, but that interface should be hidden to users.
For example defining a interface ommittng the public
keyword;

interface IRestricted{
bool Test();
}

public class Something:IRestricted
public method1(){}
bool IRestricted.Test(){};
}

In the above, Test method has been explicitly defined
and it can only be accessed internaly. public users can't
use the Test method and they can't see the IRestricted
interface either. This is what I want to get done. But the
glitch is, I can't define the IRestricted interface inside my
root namespace so that ALL MY projects will be able to see
it(which makes my projects(modules) being able to
communicate with eaach other, but still general public
wont be able to see/access those explicitly defined methods)

Is it by design or am I doing something wrong? Further more,
If I define an interface(without public keyword) inside the
root ineterface, shouldn't it be visible to ANY project inside
that root namespace?

regards
KK
 
You are actually wrong that the Test method on Something cannot be called by outsiders. The following is possible

Something s = new Something()
((IRestricted) s).Test()

Using the modifier "internal" on your interface ensures that your interface can only be used within the assembly in which it is defined. Of course, then you can not use the interface from your other assemblies.

But why is it necessary for you to make sure that other people are not using your interface? An interface does nothing by itself. If you want to make sure that other people are not calling methods on classes in your assemblies (e.g. classes implementing your interface) you can use the StrongNameIdentityPermissionAttribute to make sure that only callers signed with the key of your company can call into your classes

Regards, Jakob.
 
Jakob Christensen said:
You are actually wrong that the Test method on Something cannot be
called by outsiders. The following is possible:

Something s = new Something();
((IRestricted) s).Test();

Using the modifier "internal" on your interface ensures that your
interface can only be used within the assembly in which it is
defined.
Click to expand...

The default for an interface is "internal" though, so the OP was
entirely correct.

In C#, the default visibility is always the most restrictive applicable
one, which I find is a nice easy rule to remember.
 
KK said:
Is it possible to have a interface accessible by all the projects
in my solution, but that interface should be hidden to users.
Click to expand...

That's a problem in itself - there's no difference between a project in
your solution and a user's project, when considering another project in
your solution.
 
Hi Jakob
But why is it necessary for you to make sure that other people are not
Click to expand...
using your interface? An interface does nothing by itself. If you want to
make sure that other people are not calling methods on classes in your
assemblies (e.g. classes implementing your interface) you can use the
StrongNameIdentityPermissionAttribute to make sure that only callers signed
with the key of your company can call into your classes.
Now this is good. I mean using StrongNameIdentityPermissionAttribute to
restrict access to my methods using this. Well, I know sometimes you may
think its werid why I try to restrict users from using certain methods. well
in my situation there are 2 set of assemblies

1. Business logic
2 DataAccess layer

basicaly it should go through biz logic assmbly and then to DA assembly. but
in my situation there is a specific function, that MUST go through bizlogic.
normal users should not be able to call Add or Delete method. They should be
only talking to business logic.

Well, some might say to have DA also inside the biz logic as well to avoid
all these.. but then the project has some more which makes it imposible for
us (or impractical) to put everything inside to one project.

Anyhow, let me try this StrongNameIdentityPermissionAttribute.

thanks everybody
KK
 
Back
Top