Scope of internal method in C#?

[Adam]

I've seen lots of mentions of the scope of an "internal" class.

What's the scope of an "internal" method. Why would one use it as
opposed to an "internal" class?

Thanks in advance.

Adam

 

[Guest]

You would not use one as opposed to the other.
If you have a class that you want exposed outside of your project, then it's
public (or protected). You may have some methods in that class that are only
accessed from your project - these would be Internal methods. If you have a
class where none of the methods or fields are to be exposed outside of the
project, then the class should be Internal.

If the class-level access is more restrictive than the member-level access,
then the more restrictive access applies.

David Anton
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# converter
and the Instant VB C# to VB.NET converter

 

[Steve Walker]

I've seen lots of mentions of the scope of an "internal" class.

What's the scope of an "internal" method. Why would one use it as
opposed to an "internal" class?

Thanks in advance.

You may want a method on a public class which can be called by other
classes in the assembly, but not by clients of the assembly. Imagine you
have a container class managing a collection of Things. A Thing knows
how to delete its database record, but you want to ensure that when a
Thing is deleted, it is also removed from the collection:

public class ThingCollection
{
private Hashtable things;
public void DeleteThing(Thing toDelete)
{
toDelete.Delete();
this.things.Remove(toDelete.ID);
}
}
public class Thing
{
internal void Delete()
{
//Delete from database
}
}

 

[Bob Powell [MVP]]

A class with internal access is visible to all other classes within the same
assembly. A method with internal access can be considered as if it were
public within the same assembly and private elsewhere.

This enables you to create classes which only expose a limited number of
their total methods to consumers of the assembly while enabling your own
code within the assembly priveliged assess to certain methods.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Guest]

I wish internal worked as described, but it seems to only work when it is
within one file. This seems rather strange, as there is no abstaction level
of "file" in C# that the programmer observes (yes I know the blob behind
knows files).
Personally I think internal should abstract to the name space, something
that actually exists to the programmer. This would also simplify export of
dll files.

 

[Jon Skeet [C# MVP]]

I wish internal worked as described, but it seems to only work when it is
within one file.

No, that's not true. If you're running into it as a problem, could you
post a short but complete program which demonstrates it?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

This seems rather strange, as there is no abstaction level
of "file" in C# that the programmer observes (yes I know the blob behind
knows files).
Personally I think internal should abstract to the name space, something
that actually exists to the programmer. This would also simplify export of
dll files.

It would be useful to have a namespace access modifier, but internal is
useful too. It's a pain with .NET having one and Java having the other
- it would be so nice to have one environment with both...

(The idea of an assembly definitely exists to the programmer, IMO.)

 

[Guest]

So I went to collect the screens and found something very interesting.
First I am using VS2003.NET on W2k.
First I take a class and change it from public to internal.
I then change the instanuation to internal for proper scope.
Then I do a "Build".
Errors spring up for every use of the class about protection levels.
I then change ANY of the called routines from public to internal.
Then I do a "Build".
No errors!
I then switch the called routine back to public .
Then I do a "Build".
No errors!
It seems to work from then on...
Think the partial build command misses the change?
(I haven't tried ReBuild on the first change)

 

[Jon Skeet [C# MVP]]

So I went to collect the screens and found something very interesting.
First I am using VS2003.NET on W2k.
First I take a class and change it from public to internal.
I then change the instanuation to internal for proper scope.
Then I do a "Build".
Errors spring up for every use of the class about protection levels.
I then change ANY of the called routines from public to internal.
Then I do a "Build".
No errors!
I then switch the called routine back to public .
Then I do a "Build".
No errors!
It seems to work from then on...
Think the partial build command misses the change?
(I haven't tried ReBuild on the first change)

It's possible. I've seen VS.NET get its knickers in a twist like that
before, occasionally. A rebuild usually sorts things out.