I have seen it in many projects. Why do developers use internal classes to store the constant variables in C#?
For instance:
internal static class Constants
{
public const double Pi = 3.14159;
public const int SpeedOfLight = 300000; // km per sec.
}
Simply, the designer decided that this class need to be used within the same assembly. And it is not to be exposed to or accessed from any project referencing the assembly.
When you download a Nuget package, you can't access classes that are internal. The developers decided that you don't need to access these. So these values are "private" for this package.
More on access modifiers:
public :Access is not restricted.
protected :Access is limited to the containing class or types derived from the containing class.
internal: Access is limited to the current assembly.
protected internal : Access is limited to the current assembly or types derived from the containing class.
private : Access is limited to the containing type.
Because when constants are publicly exposed (instead of internal), the danger exists that when an outside assembly references them, it may become "out of date" when the assembly that declares them is updated with new constant values, but the referencing assembly is not re-compiled.
Say, for example, the referenced assembly containing the "updated" constant values forms part of a "plugin" architecture, where a new version of the plugin could simply be "dropped" into the referencing application's folder without recompiling and redeploying the application. Even if the application that referenced a constant from the "plugin" assembly that originally declared it, the application will not use the new updated values, and will continue using the old ones instead.
This happens because when the compiler sees a constant, it "inlines" its value into the expressions or statements that contain ("reference") it, wherever that may be.
To solve this problem, and you really want to expose a "constant" to the outside world, rather declare the symbol as public static readonly. That way, if the value is ever updated, any outside assemblies that reference it will automatically use the update value(s), even without needing a recompile.
But if you really want to use const instead, make sure it is really a constant that will never change, i.e. laws of nature, physical constants, like Pi.
While most answers describe the meaning of internal they are missing a part of the question I think: Why put constants in a inner class?
This is mostly because it can they desire to identify constants through something feeling like a namespace:
double myValue = Constants.Pi * 10;
Or
double myValue = OtherClass.Constants.Pi * 10;
Without the inner class they would look more like members/properties. At least when they do not use UPPER_CASING for the naming.
To make the answer complete: The internal is used to protect the constant against using them outside of the assembly.
In a contract project I have defined some interface e.g.
public interface IProject : INotifyPropertyChanged
{
string Path { get; }
}
The interface is exposed to various front-ends (e.g WPF, command line etc.) by referencing the contracts assembly.
It is exposing only the getter of Path as no user should be able to modify if. Every modification happens in the runtime assembly.
The runtime project, which does all the heavy work implements am internal Project and of course needs some sort of setter for Path (property, ctor, etc.)
The runtime creates a Project but returns an IProject to the user to satisfy the contract.
When the user performs an action on the IProject e.g.
runtime.SetPath(iProjectObject, "my new path");
what is a proper way of obtaining a valid Project from the interfaced passed to SetPath ?
Is casting (and therefore unboxing) the way to go?
It somehow seems dirty to me to define nice contracts and then cast around.
However it is possible to assume that IProject will always be Project as it is created and managed by the runtime assembly only. But I cannot guarantee that a user does not derive from IProject and feed it into my runtime.
Non-casting alternatives like runtime having a map of IProject to Project references seems odd as they would basically point to the same object.
So every public runtime method dealing with IProject will need boilerplate for casting, assumptions, throwing on wrong type etc?
From a design perspective, if your consumer (runtime.SetPath) requires a Project instance and not simply the implementation of iProject then SetPath does not actually conform to the iProject interface contract to begin with, since it requires a cast to do anything useful with iProjectObject instead of treating it AS iProject.
This sounds instead like a good case for an abstract Project class that does the minimum Project relevant implementation necessary to satisfy the runtime while also allowing the user to subclass. This would eliminate that boilierplate unboxing / trycast stuff too.
use a mark interface, and makes it internal in your runtime assembly, and the let your service inherit form both the IProject and the mark interface. The when the runtime get the IProject instance, check if it is also type of the mark interface.
The code will like this in the runtime assembly :
internal interface IProjectTag{};
internal class ProjectService: IProject,IProjectTag{
public void SetPath
{
if (this is IProjectTag)
{...}
}
}
My C# project has references to two third party DLLs. This is important because it means I don't have access to source code and can't modify or recompile these two DLLs.
Let's call them dll A and dll B. Here's what dll A looks like:
namespace ThirdParty.Foo
{
public class Bar
{
...snip...
}
public class Something
{
public Bar MyProperty { get; set; }
}
}
And here's what dll B looks like:
namespace ThirdParty.Foo
{
public class Bar
{
...snip...
}
public class SomethingElse
{
public Bar MyProperty { get; set; }
}
}
As you can see, they have the same namespace and they both define a class with the same name. My C# code needs a reference to both DLLs. I use the alias property on the reference to be able to distinguish between the two references and I also extern alias firstDll and extern alias secondDll at the top of my C# file. So far so good.
It seems obvious to me that the type of Something.MyProperty is firstDll.ThirdParty.Foo.Bar and the type of SomethingElse.MyProperty is secondDll.ThirdParty.Foo.Bar but for some reason, Visual Studio gets confused and resolves the type of both properties to the same Bar class in firstDll.
Is there a way for me to "force" VisualStudio to resolve the correct type?
EDIT:
the error I'm getting in Visual Studio is: Cannot implicitly convert type 'ThirdParty.Foo.Bar [d:\MySolution\References\Second.dll]' to 'ThirpParty.Foo.Bar [d:\MySolution\References\First.dll]'
Create a DLL that will serve as a wrapper for DLL A. Let's call the new DLL "C". Your project will then reference DLL B and C.
If the two types have the same name and namespace, then you are pretty much stuck. In C#, the name/identifier is quite important, "best fit" will only work in special situations.
However, you could write wrappers for the two different types, and make those wrappers have different names. By having two different (or even one) project just for the wrapper, you could have only one reference, thus effectively resolving the conflict "by force".
Something that works(for me it did referenced correctly) is the following,first(as you probably already did)click each dll in the references and assign an alias and place the proper extern alias.After to use the class Something and SomethingElse(and properly assign the Bar Property) create one class for each of those classes(Something and SomethingElse)and derive from them and shadow the MyProperty property:
public class TestFirst : first.ThirdParty.Foo.Something
{
//here you shadow and since you must provide the alias
//and the fully qualified name it will bet set to the
//right Bar class,same bellow in testsecond.
public first.ThirdParty.Foo.Bar MyProperty { get; set; }
}
public class TestSecond : second.ThirdParty.Foo.SomethingElse
{
public second.ThirdParty.Foo.Bar MyProperty { get; set; }
}
After its just business as usual:
TestSecond t = new TestSecond();
t.MyProperty = new second.ThirdParty.Foo.Bar();
I would load the dlls explicitly via Assembly.Load then do a createinstance on the types you need then invoke the methods via dynamic - that's because I am lazy.
The other (not lazy) way is to then use reflection to find the method and invoke it.
Since you have an extreme case here where the two assemblies not only have the same namespace, but also the same full assembly name (meaning the types have the same assembly-qualified name), you may want to consider more extreme measures to resolve it. If it's a fully managed DLL (no native code mixed in) and not strong named (or you're okay with removing the strong naming), you may be able to get away with a procedure like this:
Run ildasm and output to a .il file on disk.
Modify the .il file using a careful search and replace to change the root namespace for all types (be cautious for inner namespaces or type names that contain the same text as the root namespace.)
Run the modified file through ilasm to build a new .dll with the changes.
You can use the keyword var instead of specifying the type explicitly to avoid ambiguous references
var x = new ThirdParty.Foo.Something();
var y = new ThirdParty.Foo.SomethingElse();
var barX = x.MyProperty;
var barY = y.MyProperty;
I'm writing a library which is shared between .net and silverlight. I have several places where I am doing this, to satisfy the silverlight deserialization (which can't access private members):
[DataMember (IsRequired = true)]
public Object MyProperty { get;
#if SILVERLIGHT
internal
#else
private
#endif
set; }
I know the rules for this, which are that if the setter is private and SILVERLIGHT is defined then the setter should be internal.
Could I use an aspect oriented framework like postsharp to help me reduce this code so that I don't need to specify anything and it will inspect the property, if it has the DataMember attribute and the setter is private, then make the setter internal instead?
Or is there some other technique I could use for this?
EDIT
There seems to be some confusion. My goal is to avoid having the compiler directives at all, but to still have code which is generated with a private member in .net and with a member that can be set by the DataContractDeserializer in Silverlight, which can't access private members. If possible I'd like to automatically modify the property in a silverlight build so it is internal, whilst not having anything other than the DataMember attribute in the source.
Ideally I see the solution being something like:
Write an aspect which checks every property or field.
If the property/field has the [DataMember] attribute then
If the silverlight compiler directive exists then
if the setter is private make it internal (for properties) or if it is declared as private make it internal (for fields)
but I'm not sure which bits of that it would be possible to do using a tool like post sharp.
The other answers either attack the merit of the problem or present alternative approaches that do not directly answer the question. The question was whether there was a way to change the visibility of the setter for a property with a DataMember attribute after it is compiled, to support two versions (.NET and Silverlight).
I suspect the PostSharp SDK would support this. However, this is a problem I had to solve while developing Afterthought, as I needed to change the visibility of anonymous static delegates generated by the C# compiler (normally private until I made them internal). Afterthought itself does not currently support your scenario directly, but it leverages the open source Microsoft CCI libraries, which do. The IL Mutator example shows how to use the CCI libraries to load a compiled assembly and modify it by creating a mutable copy. The example is actually much more complex than your scenario, as you will not be modifying IL, just the visibility of a setter.
This is an example of changing the visibility of a method from within a mutator in CCI:
public override MethodDefinition Mutate(MethodDefinition methodDef)
{
// Automatically make all private static methods to have internal scope
if (methodDef.IsStatic && methodDef.Visibility == TypeMemberVisibility.Private)
methodDef.Visibility = TypeMemberVisibility.Assembly;
This is a slightly simplified excerpt from the Afterthought amender. There are also examples in the same class for how to determine if a method is a setter (starts with set_, HideBySig, etc). You would just need to create a mutator, override the method in this example, verify that the method is a property setter with a DataMember attribute on the containing property definition, and change the visibility.
Simple answer is NO. PostSharp is a Post-Compile framework so you cannot use your compiler directives (as you're trying to do in your question). You can use PostSharp to
Introduce properties into the class with the accessors desired (which doesn't give you access at design time) Directives can be applied to the aspect at design time to determine which property to inject though
Or use reflection to change the accessor (I dont think you can do that)
An alternative is to use T4 templates to generate these classes for you
Edit: Example of property injection
[Serializable]
[MulticastAttributeUsage(MulticastTargets.Class, Inheritance = MulticastInheritance.Strict)]
public class PropInj : InstanceLevelAspect
{
#if SILVERLIGHT
[IntroduceMember(OverrideAction = MemberOverrideAction.Ignore, IsVirtual=true, Visibility=Visibility.FamilyAndAssembly)]
public string MyProperty { get; set; }
#else
[IntroduceMember(OverrideAction = MemberOverrideAction.Ignore, IsVirtual = true, Visibility = Visibility.Private)]
public string MyProperty { get; set; }
#endif
}
[PropInj]
public class test
{
//public int MyProperty { get; set; }
public test()
{
}
}
but really you need to rethink your design.
Could you please explain what the practical usage is for the internal keyword in C#?
I know that the internal modifier limits access to the current assembly, but when and in which circumstance should I use it?
Utility or helper classes/methods that you would like to access from many other classes within the same assembly, but that you want to ensure code in other assemblies can't access.
From MSDN (via archive.org):
A common use of internal access is in component-based development because it enables a group of components to cooperate in a private manner without being exposed to the rest of the application code. For example, a framework for building graphical user interfaces could provide Control and Form classes that cooperate using members with internal access. Since these members are internal, they are not exposed to code that is using the framework.
You can also use the internal modifier along with the InternalsVisibleTo assembly level attribute to create "friend" assemblies that are granted special access to the target assembly internal classes.
This can be useful for creation of unit testing assemblies that are then allowed to call internal members of the assembly to be tested. Of course no other assemblies are granted this level of access, so when you release your system, encapsulation is maintained.
If Bob needs BigImportantClass then Bob needs to get the people who own project A to sign up to guarantee that BigImportantClass will be written to meet his needs, tested to ensure that it meets his needs, is documented as meeting his needs, and that a process will be put in place to ensure that it will never be changed so as to no longer meet his needs.
If a class is internal then it doesn't have to go through that process, which saves budget for Project A that they can spend on other things.
The point of internal is not that it makes life difficult for Bob. It's that it allows you to control what expensive promises Project A is making about features, lifetime, compatibility, and so on.
Another reason to use internal is if you obfuscate your binaries. The obfuscator knows that it's safe to scramble the class name of any internal classes, while the name of public classes can't be scrambled, because that could break existing references.
If you are writing a DLL that encapsulates a ton of complex functionality into a simple public API, then “internal” is used on the class members which are not to be exposed publicly.
Hiding complexity (a.k.a. encapsulation) is the chief concept of quality software engineering.
The internal keyword is heavily used when you are building a wrapper over non-managed code.
When you have a C/C++ based library that you want to DllImport you can import these functions as static functions of a class, and make they internal, so your user only have access to your wrapper and not the original API so it can't mess with anything. The functions being static you can use they everywhere in the assembly, for the multiple wrapper classes you need.
You can take a look at Mono.Cairo, it's a wrapper around cairo library that uses this approach.
Being driven by "use as strict modifier as you can" rule I use internal everywhere I need to access, say, method from another class until I explicitly need to access it from another assembly.
As assembly interface is usually more narrow than sum of its classes interfaces, there are quite many places I use it.
I find internal to be far overused. you really should not be exposing certain functionailty only to certain classes that you would not to other consumers.
This in my opinion breaks the interface, breaks the abstraction. This is not to say it should never be used, but a better solution is to refactor to a different class or to be used in a different way if possible. However, this may not be always possible.
The reasons it can cause issues is that another developer may be charged with building another class in the same assembly that yours is. Having internals lessens the clarity of the abstraction, and can cause problems if being misused. It would be the same issue as if you made it public. The other class that is being built by the other developer is still a consumer, just like any external class. Class abstraction and encapsulation isnt just for protection for/from external classes, but for any and all classes.
Another problem is that a lot of developers will think they may need to use it elsewhere in the assembly and mark it as internal anyways, even though they dont need it at the time. Another developer then may think its there for the taking. Typically you want to mark private until you have a definative need.
But some of this can be subjective, and I am not saying it should never be used. Just use when needed.
This example contains two files: Assembly1.cs and Assembly2.cs. The first file contains an internal base class, BaseClass. In the second file, an attempt to instantiate BaseClass will produce an error.
// Assembly1.cs
// compile with: /target:library
internal class BaseClass
{
public static int intM = 0;
}
// Assembly1_a.cs
// compile with: /reference:Assembly1.dll
class TestAccess
{
static void Main()
{
BaseClass myBase = new BaseClass(); // CS0122
}
}
In this example, use the same files you used in example 1, and change the accessibility level of BaseClass to public. Also change the accessibility level of the member IntM to internal. In this case, you can instantiate the class, but you cannot access the internal member.
// Assembly2.cs
// compile with: /target:library
public class BaseClass
{
internal static int intM = 0;
}
// Assembly2_a.cs
// compile with: /reference:Assembly1.dll
public class TestAccess
{
static void Main()
{
BaseClass myBase = new BaseClass(); // Ok.
BaseClass.intM = 444; // CS0117
}
}
source: http://msdn.microsoft.com/en-us/library/7c5ka91b(VS.80).aspx
Saw an interesting one the other day, maybe week, on a blog that I can't remember. Basically I can't take credit for this but I thought it might have some useful application.
Say you wanted an abstract class to be seen by another assembly but you don't want someone to be able to inherit from it. Sealed won't work because it's abstract for a reason, other classes in that assembly do inherit from it. Private won't work because you might want to declare a Parent class somewhere in the other assembly.
namespace Base.Assembly
{
public abstract class Parent
{
internal abstract void SomeMethod();
}
//This works just fine since it's in the same assembly.
public class ChildWithin : Parent
{
internal override void SomeMethod()
{
}
}
}
namespace Another.Assembly
{
//Kaboom, because you can't override an internal method
public class ChildOutside : Parent
{
}
public class Test
{
//Just fine
private Parent _parent;
public Test()
{
//Still fine
_parent = new ChildWithin();
}
}
}
As you can see, it effectively allows someone to use the Parent class without being able to inherit from.
When you have methods, classes, etc which need to be accessible within the scope of the current assembly and never outside it.
For example, a DAL may have an ORM but the objects should not be exposed to the business layer all interaction should be done through static methods and passing in the required paramters.
A very interesting use of internal - with internal member of course being limited only to the assembly in which it is declared - is getting "friend" functionality to some degree out of it. A friend member is something that is visible only to certain other assemblies outside of the assembly in which its declared. C# has no built in support for friend, however the CLR does.
You can use InternalsVisibleToAttribute to declare a friend assembly, and all references from within the friend assembly will treat the internal members of your declaring assembly as public within the scope of the friend assembly. A problem with this is that all internal members are visible; you cannot pick and choose.
A good use for InternalsVisibleTo is to expose various internal members to a unit test assembly thus eliminating the needs for complex reflection work arounds to test those members. All internal members being visible isn't so much of a problem, however taking this approach does muck up your class interfaces pretty heavily and can potentially ruin encapsulation within the declaring assembly.
As rule-of-thumb there are two kinds of members:
public surface: visible from an external assembly (public, protected, and internal protected):
caller is not trusted, so parameter validation, method documentation, etc. is needed.
private surface: not visible from an external assembly (private and internal, or internal classes):
caller is generally trusted, so parameter validation, method documentation, etc. may be omitted.
Noise reduction, the less types you expose the more simple your library is.
Tamper proofing / Security is another (although Reflection can win against it).
Internal classes enable you to limit the API of your assembly. This has benefits, like making your API simpler to understand.
Also, if a bug exists in your assembly, there is less of a chance of the fix introducing a breaking change. Without internal classes, you would have to assume that changing any class's public members would be a breaking change. With internal classes, you can assume that modifying their public members only breaks the internal API of the assembly (and any assemblies referenced in the InternalsVisibleTo attribute).
I like having encapsulation at the class level and at the assembly level. There are some who disagree with this, but it's nice to know that the functionality is available.
One use of the internal keyword is to limit access to concrete implementations from the user of your assembly.
If you have a factory or some other central location for constructing objects the user of your assembly need only deal with the public interface or abstract base class.
Also, internal constructors allow you to control where and when an otherwise public class is instantiated.
I have a project which uses LINQ-to-SQL for the data back-end. I have two main namespaces: Biz and Data. The LINQ data model lives in Data and is marked "internal"; the Biz namespace has public classes which wrap around the LINQ data classes.
So there's Data.Client, and Biz.Client; the latter exposes all relevant properties of the data object, e.g.:
private Data.Client _client;
public int Id { get { return _client.Id; } set { _client.Id = value; } }
The Biz objects have a private constructor (to force the use of factory methods), and an internal constructor which looks like this:
internal Client(Data.Client client) {
this._client = client;
}
That can be used by any of the business classes in the library, but the front-end (UI) has no way of directly accessing the data model, ensuring that the business layer always acts as an intermediary.
This is the first time I've really used internal much, and it's proving quite useful.
There are cases when it makes sense to make members of classes internal. One example could be if you want to control how the classes are instantiated; let's say you provide some sort of factory for creating instances of the class. You can make the constructor internal, so that the factory (that resides in the same assembly) can create instances of the class, but code outside of that assembly can't.
However, I can't see any point with making classes or members internal without specific reasons, just as little as it makes sense to make them public, or private without specific reasons.
the only thing i have ever used the internal keyword on is the license-checking code in my product ;-)
How about this one: typically it is recommended that you do not expose a List object to external users of an assembly, rather expose an IEnumerable. But it is lot easier to use a List object inside the assembly, because you get the array syntax, and all other List methods. So, I typically have a internal property exposing a List to be used inside the assembly.
Comments are welcome about this approach.
Keep in mind that any class defined as public will automatically show up in the intellisense when someone looks at your project namespace. From an API perspective, it is important to only show users of your project the classes that they can use. Use the internal keyword to hide things they shouldn't see.
If your Big_Important_Class for Project A is intended for use outside your project, then you should not mark it internal.
However, in many projects, you'll often have classes that are really only intended for use inside a project. For example, you may have a class that holds the arguments to a parameterized thread invocation. In these cases, you should mark them as internal if for no other reason than to protect yourself from an unintended API change down the road.
The idea is that when you are designing a library only the classes that are intended for use from outside (by clients of your library) should be public. This way you can hide classes that
Are likely to change in future releases (if they were public you would break client code)
Are useless to the client and may cause confusion
Are not safe (so improper use could break your library pretty badly)
etc.
If you are developing inhouse solutions than using internal elements is not that important I guess, because usually the clients will have constant contact with you and/or access to the code. They are fairly critical for library developers though.
When you have classes or methods which don't fit cleanly into the Object-Oriented Paradigm, which do dangerous stuff, which need to be called from other classes and methods under your control, and which you don't want to let anyone else use.
public class DangerousClass {
public void SafeMethod() { }
internal void UpdateGlobalStateInSomeBizarreWay() { }
}