I have the following code returning the error " 'object' does not contain a constructor that takes x arguments." on the line trying to call the base constructor.
Solution 1, project 1
namespace Project.Sub.A
{
internal class Foo
{
internal Foo(int a, long b) {}
}
}
Solution 1,project 2
namespace Project.Sub.B{
internal class Bar : Foo
{
internal Bar(int a, long b,long c) :base(a,b+c) {}
}
}
I have NO idea why this does not want to work. Could be my namespaces configured incorrectly?
internal access is per assembly, not namespace.
Because the constructor in the base class is declared internal, it is not accessible to the subclass in the other project. Try changing it to protected internal, or just protected.
update
Just noticed that the base class is also internal. You will need to make it public if you want it to be seen in the second project. Or, you can add [assembly:InternalsVisibleTo("Project2")] in AssemblyInfo.cs in Project1. (I wouldn't personally recommend this option, though.)
There are a number of confounding issues here.
First, your classes are defined as internal in two separate projects. internal means that a class is only visible within its own assembly and not to client code outside of the assembly. Foo should be public so that it can be used in other assemblies
If you make class Foo visible outside of the assembly then you will have to reference that assembly from the project that contains class Bar
And you will have to make sure that the namespaces are referenced properly as well
internal means visible to other classes in the current assembly
Because you're defining your second class in a second project, it can't see that base constructor.
Try making both the Foo Class & Constructor protected instead or internal.
If it's in a separate project as your question suggests, and your base class is marked internal, then it shouldn't be able to find the entire type, let alone the constructor.
Change Foo' accessor to public.
Related
I have a DLL that I'm making for Windows Forms applications. The layout looks a little something like this
public class A : UserControl
{
protected C c;
}
public class B : A { }
public class C { }
I want the DLL to only export class B, but it will not compile if I remove the public qualifier from A or C. Is there a way to do this?
Error from removing public from A:
Error CS0060 Inconsistent accessibility: base class 'A' is less accessible than class 'B'
From MSDN - Restrictions on Using Accessibility Levels (C# Reference):
When you specify a type in a declaration, check whether the accessibility level of the type is dependent on the accessibility level of a member or of another type. For example, the direct base class must be at least as accessible as the derived class.
Usually, in order to hide "stuff" from others, what you do, is provide a public interface and hide all the sub-classes. You can let your client create the concrete classes with a public factory which you will provide as well.
Not possible. If B inherits A, you simply cannot expose B without exposing A.
I have a few differenet namespaces in my solution and I want to use an object called "Doctor" from namespece BL_Backend inside another namespace called DAL. I've tried adding a Refference to DAL (a refference for BL_Backend), and then adding "using BL_Backend;" but it wouldn't work. still classes such as Doctor won't appear as known ones inside namespace DAL.
namespace BL_Backend
{
…
namespace DAL
{
…
//Here create object as "Doctor" for BL_Backend class
}
}
For example,
when i call a constructor of a doctor from DAL it says this constructor does not exists but when i write the exact same command at namespace bl_backend it works fine.
thanks alot!
I assume Doctor is declared as internal class in BL_Backend assembly. Note - if class does not have public access modifier, then by default it will be internal:
namespace BL_Backend
{
class Doctor // this class is internal
{
}
}
Internal classes are visible only within assembly they are defined (well, there is attribute InternalsVisibleTo which allows other assemblies to see internal classes, but without applying this attribute, class is not visible to other assemblies).
If you want to use a class Doctor from an assembly BL_Backend in a DAL you must add a reference in DAL to the BL_Backend not vise versa.
Classes without a modifier are internal by default, so ensure that your modifier is public.
As a second option pay attention to the build order - its not a problem in VS12+ anymore, but in further versions it was.
I tried to make a class as private and got this Error "Elements defined in a namespace cannot be explicitly declared as private, protected, or protected internal"
I got its meaning but I want to ask why this is not allowed? Are all access modifires not applicable on Class? Why I can't make a class private, protected or protected internal?
Because private means that the member is only visible in the containing class. Since a top-level class has no class containing it it cannot be private (or protected).
(Internal or public are valid modifiers though).
What would you want private to mean on a top-level class?
Of course all modifiers apply to nested classes, i.e. a class defined within another class.
You can use only public or internal in the Namespace level
As Abatonime said, you can only use public or internal in the Namespace level.
private, protected, or protected internal can only be used in the Class level.
This works
namespace X
{
class A
{
// class code here
private class B // this class is an inner class
{
// class code here
}
}
}
This won't
namespace X
{
class A
{
// class code here
}
private class B // this is a class inside a namespace
{
// class code here
}
}
Because it doesn't make sense. There's no way you can access protected or private classes defined at namespace level, only as nested classes.
Only nested classes could be declared as private.
Not nested classes can be only public or internal (implicit without modifiers)
I had this same problem because I was creating a custom DLL and only wanted certain classes to be visible to an application using the DLL. So I just remove the modifier completely for classes I wanted to be private (within specific namespaces). The classes remained accessible to other classes within the same namespace in the DLL but did not show up in Intellisense in the calling application. No need for nested classes. The only explanation I can think of is the error message says cannot "explicitly" declare private...it doesn't say anything about implicitly.
namespace SmartCardAuthentication
{
class SmartCardIdentity : IIdentity
{
private string _firstName;
private string _lastName;
private string _middleInitial;
....
}
}
In example code above, class "SmartCardIdentity" is available to other class within same namespace, but not available to calling application when this class is rolled into a DLL. I have not tested it anyother way (i.e. visibility from a class in a different namespace within the DLL.).
The default accessibility of top-level types is internal.
The default accessibility of class and struct members is private.
The only possible accessibility of interface and enum members is public.
So a class is by default private, and if you want to access that, you have to put public before that.
Only Public and Internal are applicable when defining class. If no access modifier is defined before the class default is internal.
refer to MSDN - [https://msdn.microsoft.com/en-us/library/8fd16xs0(v=vs.90).aspx]
In real world we are focus on visible object
Once object is visible then we talk about scope of the object
example in real world
If you walking on street, you see houses in a colony
colony has houses.
If colony is protected no one can't able to see houses
It is consider that no colony no houses is present
In Programming
If we make class as private/ protected at top-level
no one known about it
is it present in assembly ?
please correct me, if i am out of the scope
What is the difference between the internal and private access modifiers in C#?
internal is for assembly scope (i.e. only accessible from code in the same .exe or .dll)
private is for class scope (i.e. accessible only from code in the same class).
Find an explanation below. You can check this link for more details -
http://www.dotnetbull.com/2013/10/public-protected-private-internal-access-modifier-in-c.html
Private: - Private members are only accessible within the own type (Own class).
Internal: - Internal member are accessible only within the assembly by inheritance (its derived type) or by instance of class.
Reference :
dotnetbull - what is access modifier in c#
internal members are visible to all code in the assembly they are declared in.
(And to other assemblies referenced using the [InternalsVisibleTo] attribute)
private members are visible only to the declaring class. (including nested classes)
An outer (non-nested) class cannot be declared private, as there is no containing scope to make it private to.
To answer the question you forgot to ask, protected members are like private members, but are also visible in all classes that inherit the declaring type. (But only on an expression of at least the type of the current class)
Private members are accessible only within the body of the class or the struct in which they are declared.
Internal types or members are accessible only within files in the same assembly
private - encapsulations in class/scope/struct ect'.
internal - encapsulation in assemblies.
internal members are accessible within the assembly (only accessible in the same project)
private members are accessible within the same class
Example for Beginners
There are 2 projects in a solution (Project1, Project2) and Project1 has a reference to Project2.
Public method written in Project2 will be accessible in Project2 and the Project1
Internal method written in Project2 will be accessible in Project2 only but not in Project1
private method written in class1 of Project2 will only be accessible to the same class. It will neither be accessible in other classes of Project 2 not in Project 1.
Internal will allow you to reference, say, a Data Access static class (for thread safety) between multiple business logic classes, while not subscribing them to inherit that class/trip over each other in connection pools, and to ultimately avoid allowing a DAL class to promote access at the public level. This has countless backings in design and best practices.
Entity Framework makes good use of this type of access
Suppose that we have a class named class1.
The class1 has several properties and methods and we have decided to specify the access specifier of class1 as internal.
Now, can we set the access specifier of class1 methods as public?
For your specific question, Class 1 which is declared as internal can have a public method.
Why?
Look at Jon Skeets explanation:
You can certainly mark a class as
internal, but that's different from
making its public members internal.
For instance, suppose you have a class
which implements a public interface.
Even though the class may be internal,
an instance may still "get out of the
assembly" by being returned from a
member in another (public) class. That
instance would have to be referenced
by the interface it implements rather
than the class name itself (as the
class isn't known to the outside
assembly) but the public methods can
still be called.
If the public methods aren't
implementing any interfaces, I suspect
it would only make a difference in a
very few reflection cases which you
may not care about.
community wiki - as credit should go to Jon Skeet
Yes, you can set public on members of internal/private/etc types.
As other replies have noted, external code won't be able to see the properties unless it can see the type - but there are lots of nuances:
if the member is on an interface it will be (essentially) part of the public API
the member might be a public override of a virtual/abstract member - in which case it will truly be publicly visible, but via the base-class (again, similar to interfaces)
But there is a lot of other code in the framework that uses reflection and demands public accessibility:
data binding usually works on the public properties
security checks for partial-trust can be fussy about public members
serialization (for example XmlSerializer) may want public members
etc
So there are still lots of reasons to think about public rather than just internal, even if your code is only referenced by the local assembly.
By rule access specifiers on methods and properties can not be more more accessible than that of the class containing it.
But I've tried this:
internal class Test
{
public string Testing{get;set;}
}
and it compiles without any exception! I think it is okay as the class Test will not be accessible outside the namespace assembly we have declared so public property will not make any difference.
This does not works:
private class Test
{
public string Testing{get;set;}
internal string TestingAgain{get;set;}
}