In a single project (ie assembly) is the internal attribute any different from the public attribute?
I don't see a difference, but I wanted to make sure there are no edge cases I am not thinking of.
Yes, the difference comes in when somebody else is referencing your assembly. In that case only the public members will be visible. But don't forget, the internal/private members can still be accessed via Reflection/dynamics. Also it will no longer be labeled with the BindingFlags.Public, it uses BindingFlags.NonPublic instead.
Yes, it's the same. Internal is public within the same assembly so if you have a single assembly there is no difference
Lots of people are saying yes, but the answer really is no.
If somebody references your assembly then there is a very big difference!
In general, yes.
In very rare cases, there may be differences, especially in reflection-specific contexts. For example, Activator.CreateInstance(typeof(myType)) will succeed if the type has a public parameterless constructor, but may not if the type only has an internal one (atleast on .NET 3.5) - you will have to call the overload with nonpublic = true.
Also, note that interface implementations are always public. Consequently, Replace all -> "public" - "internal" from your editor may produce code that does not compile - the compiler will refuse to allow you to implement an interface's member with internal visibility.
From with the assembly in which it is declared it is the same.
Yes, basically internal means that classes can be only used inside your assembly, which will work the same way as public inside the assembly.
But if you think your assembly will be used by any projects, its better to use public on the classes that can be referenced.
Also if you declare a class as internal, and some method inside public, internal will override its accessibility, making it internal.
Related
I have a very simple utility program I have built in C#. It only has one namespace and one class. I am just wondering what the best practice is in regards to adding accessibility keywords to the methods/variables in this context. Is it okay to just leave the accessibility keyword out here? It seems to me that adding one will be unproductive, but the methods just feels so "naked" without one.
Best Practice is usually quoted as this:
Make everything as restrictive as possible and only unrestrict when neccessary
The defaults are this in C#
classes: internal
class members: private
Private classes unless nested are rarely useful, but never mind that.
Now the last bit is my opinion. Code readability and ease of understanding is sooooo important and so I would say that it best to explicitly put the access levels in even if they are the same as the default
Leaving them out is the same as whatever the most restrictive possible is (so private for within a class and internal for a class itself within a namespace).
Technically it makes no difference whether you explicitly write private or leave it out. As a matter of convention it's more common to be explicit (include the private) and it's good to get into the habit of following common convention, so worth doing for that matter alone.
Leaving off an access modifier when declaring a code element means the compiler will provide a default access level. In your case, the class (a top-level type) would be internal and its members would be private. This is suitable for a standalone utility which you do not expect to be referenced by any other code (internal means "only this assembly (EXE/DLL) can see this" and private means "only the class/struct that declares this can see this"). Whether you want to include or leave off the keywords is a matter of style.
Mark them as they would be used if they were in a larger application.
You never know when you might migrate this code into a larger app.
Also, 6 or 7 letters to be explicit and not have yourself or someone else later on wondering what your intentions were seems a small price to pay
Lately I found a few tools that allow the .Net Library to be merged within the windows application.
Now the real question is how does the behavior of the library changes,
Does the internal class remain internal to library? Or does it become internal to the application it's been merged with?
Are there chances that library will malfunction?
Extending question:
Won't it be better that when merging the assembly that are internal should be made private so that that can't be used by the application they are merged in?
Classes can't be private unless they're nested.
But consider this: if you're merging assemblies A and B, then you must have already compiled them before merging. When they were compiled, the internal methods of each were inaccessible to the other. Therefore, in the merged code, there could be no method that calls internal methods of the other assembly.
Wont it be better that when merging the assembly that are internal should be made private so that that cant be used by the application they are merged in?
How would that work? If a top-level type were private, it would be accessible to no other types at all. That's why you can't define private types (unless they're nested within another type).
Suppose assembly A has classes C and D, where C is internal, and D calls some method from class C. When class C is made private (in some hypothetical version of the CTS where this is possible), class D breaks.
Top-level types, which are not nested into other types, can only have internal or public accessibility. The default accessibility for these types is internal.
From the MSDN link
1 Does the internal class remains internal to library ? or does becomes internal to the application is been merged with?
It remains internal to the application.
2 Are there chances that library will malfunction?
Technically it is possible. Suppose class A is internal to App, and also to one of the lib (with same namespace). Before merging there will not be any issue. After merging it will become issue to resolve ambiguous reference.
How The application (SmartAssemply/ILMerger) handles these is another issue (that I am not aware of)? They may choose to provide error information, or may not. They may choose to convert or may not.
Wont it be better that when merging the assembly that are internal should be made private so that that cant be used by the application they are merged in?
As specified top level types cannot be private/protected.
MSDN is quite clear on this:
Internal types or members are accessible only within files in the same assembly...
Since you merged them into a single assembly, the internal classes are accessible to all files within the merged assembly.
ILMerge can break libraries, although this only happens if the library is poorly designed.
The breakage will have nothing to do with internal. But if reflection is used to test what assembly something is loaded from, or search for a type in a specific assembly, the results will change.
I would be much more worried about the effects of merging on Code Access Security attributes than on internal. But essentially, don't merge assemblies that need to run at different levels of trust.
I have 2 forms and 1 Class.
I made the class a Static Class.
It has two methods with public modifiers.
Ex: Public string PrintHello(), Public void Task1()
I want these methods to be accessible from both Form1 and Form2.
I understand that using "Public" modifier is not good, so I've looked at "Internal" modifier and it seems to do the job.
Basically, I want to create a secure way of accessing my class.
What would be the best way of doing so and could you provide an example of how to do so ?
Thank you
Access modifiers does not provide security to you code.
Is someone really wants to use your privet methods he can use ILDASM to de-compile your code and use them, that would be just one example of many.
Access modifiers are there to to allow you to program using with an Object Oriented code design.
In general:
Private modifiers are internal to your class implementation and other classes or layers of your code dose not NEED nor want to know about there existence.
Internal modifiers are there to provide additional functionality required for the whole assembly but again they are not required for any one else (outside of the assembly) because they are implementation specific.
And finally Public modifiers are used to define the interface of your class with the outside world, these are methods and properties that should and will be used by any one that requires some sor of functionality from your code.
Depends on where you think the code that calls this methods will likely live. If it is only going to be ever called from the class that defined this method, then it should be private. If you only want to call it from the same assembly (dll) but you don't want to call the methods from other dlls, then you should make it internal. This way you can ship your dll to other projects and you don't have to worry about supporting your methods (because they won't have access to your methods).
But if you are doing a general purpose libarary/dll etc. Then the methods should be public.
It all depends on who or what you think is going to call your methods.
I have heard some people are against the use of internal modifier to hide classes and members from outside the assembly in which they are declared because it defeats the main principles of OOP. Is this really true?
Is this really true?
No, it is not true. Internal visibility modifier has its usages. There are classes which you don't want to be used outside of their containing assembly but still to be public inside the assembly. For example if you are designing an API, there might be classes that you don't want to expose to consumers of your API.
internal keyword allows developers to hide members of the assembly if it is used by another assembly. In .NET framework for example there are many types that are internal, meaning they are only required for the inner assembly usage and are not visible from outside the library. This is encapsulation on the assembly level.
Well people are free to have their opinions. I'm not sure how "internal" defeats the main principles of OOP.. perhaps a link would help me to evaluate their stance.
I use internal to hide types that I don't want anyone outside the assembly to use. This is pro-OOP in my opinion
expose behavior but hide implementation.
use the most restrictive access possible
e.g. I refactor some common code out of 2 public types ; this new type starts out as internal. Unless some client/test drives me to increase the visibility. Also I sometimes use it as a temp cheat to avoid writing tests for some types (all public types should have tests). It has served me well.
I'd like to implement an interface that resides in an external assembly. However that particular interface has been marked as "internal". Is there a way I can still implement this interface for my own classes?
I know how to call private/internal methods using reflection in C#, so I guess reflection should be used in this case too. However, I don't know how. And yes, I do know it usually isn't wise to use internal/private stuff, but in this case I see no other solution.
Update: I'm not able to edit / change the external assembly in any way. It should be left untouched.
You can't do that, unless you can change the assembly containing the interface to add an InternalsVisibleToAttribute, targeting your own assembly.
Use the InternalsVisibleToAttribute in the external assembly to point to the assembly that you want to expose internal types to.
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx
Just to get some background, presumably you want to pass the interface implementation to something else in this assembly, which is also internal, because otherwise they wouldn't have been able to compile this other assembly (it being an error to refer to an internal type in a public method's parameters).
I think you'll have to use Reflection.Emit to build a type that implements the interface, having obtained the interface's Type object by reflection. Not exactly a straightforward task, and the result will be fragile because you're digging around in the internals of someone else's assembly.
Other options:
Disassemble the other assembly, using
Reflector and that cool addin that
builds a whole project from the
assembly.
Talk to the owner of the other assembly and explain your needs to
them
I you have the source of the external assembly then you can compile it with an InternalsVisibleTo attribute pointing at your assembly. This is not a perfect solution and I often use it for unit testing rather than production code but it may be something worth looking at.
Basically all you would need to do is add the following to the AssemblyInfo.cs code-file in your project:
[assembly: InternalsVisibleTo("YourAssembly")]
If YourAssembly is strongly-named then you have to put the fully qualified name of the assembly including the entire public key (not just the token).