Default class access modifier

[Man T]

When you define a class the default is internal, right?
eg.
class myClass
{
}

I got a class library contains this class.

But why if when creating a new project (eg. Console application) and add
this class library as references, this myClass can be called/instantiated?

 

[Man T]

When you define a class the default is internal, right?

A top-level class, yes.

In general, the default accessibility is the most restrictive
accessibility that can be used without hiding the modified item
altogether. Top-level classes default to internal, most everything else
defaults to private, including nested classes. You can get a complete
run-down of the possibilities here:
http://msdn.microsoft.com/en-us/library/ba0a1yw2.aspx


Impossible to say without knowing exactly the code where the class is
declared, and how the code is referenced.

Hi,

I am reading the book Beginning Visual C# 2008 by Wrox.
The chapter is talking about defining a class:
First, create a class library (eg. classlibrary1, add the code of this
myClass with empty code(ie. no members).
ie.
class myClass
{
}

Then create a console application, under solution explorer, add references
this class library (eg. c:\exercise\classlibrary.dll).
Then in the main method of the console application, instantiate the myClass:
myClass objA = new myClass();
Console.WriteLine(objA.ToString());
Console.ReadKey;

Just wonder if myClass is 'Internal', how come the console application can
instantiate the myClass?

 

[Man T]

Just wonder if myClass is 'Internal', how come the console application

The only way it can is if myClass is in the same assembly as the code
using it, or it has an explicit "public" access modifier.

If you are sure that you did not include "public" as the access modifier,
then it must be in the same assembly.

Here's the class library code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Ch09ClassLib
{
class MyExternalClass
{
}
}


Here's the console application:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Ch09ClassLib;

namespace Ch09Ex02
{
class Program
{
static void Main(string[] args)
{
MyExternalClass myObj = new MyExternalClass();
Console.WriteLine(myObj.ToString());
Console.ReadKey();
}
}
}

I compiled and get the compilation error:
'Ch09ClassLib.MyExternalClass' is inaccessible due to its protection level.


I think it was working before because I added the 'public':

namespace Ch09ClassLib
{
public class MyExternalClass
{
}
}

So this book has this error.
Please if someone is/are reading this book, can you guys tell me that's the
book's mistake or my fault?
Beginning Microsoft Visual C# 2008
ISBN:978-0-470-19135-4
Wrox

 

[Man T]

Please if someone is/are reading this book, can you guys tell me that's

If the book specifically instructs you to make the class in an separate
assembly (i.e. in its own DLL...note that you can have multiple source
files, with their own namespaces, in the same project...just because it's
supposed to be in a different namespace, that doesn't necessarily mean it
has to be in a different project), _and_ the book specifically instructs
you to create the class without the "public" modifier (whether that's an
explicit instruction, or simply implied from some code example you're
supposed to type in), then that would be a mistake in the book.

It certainly wouldn't be the first time a programming book had a mistake
in it. It's probably not even the only mistake in that book.

Can someone if they have this book please read the page 230 (Chapter 9). I
hope I did not misread the 'Try It Out' example.

 

[Ben Voigt [C++ MVP]]

[...]
Just wonder if myClass is 'Internal', how come the console application
can
instantiate the myClass?

The only way it can is if myClass is in the same assembly as the code
using it, or it has an explicit "public" access modifier.

If you are sure that you did not include "public" as the access modifier,
then it must be in the same assembly.

You forgot the never-to-be-sufficiently-damned InternalsVisibleToAttribute.
Which is not unusual because most of the Microsoft documentation forgot it
as well.