I'm looking through some existing code in a project I'm working on, and I found a class that is implemented as:
public class ThingOne
{
private int A;
private int B;
[NonSerialized]
private System.Timers.Timer timer1;
}
Shouldn't it look more like this?
[Serializable]
public class ThingOne
{
private int A;
private int B;
[NonSerialized]
private System.Timers.Timer timer1;
}
Or is there some additional benefit to adding [NonSerialized] even when the class itself is not Serializable?
Or is there some additional benefit to adding [NonSerialized] even when the class itself is not Serializable?
The class isn't sealed, so another class could inherit from that object. That class could be marked as Serializable, and then the NotSerializable attribute would come into play. (although as pointed out not for private members).
Remember you can check attributes by reflection too. It may not be used by the runtime to check what should and should not be serialized, it could be used as a marker for something else in the program dealing with some sort of custom serialization (I'm not saying this is a good idea in the least).
NonSerialized will have no effect when Serializable is not used. By default, classes and their members are non-serializable.
The only advantage of declaring something NonSerialized when the class isn't serialized is under the circumstances that the class is inherited by a Serialized object, and then the inherited member will be non-serializable.
From MSDN:
'NonSerialized' attribute will not
affect this member because its
containing class is not exposed as
'Serializable'.
By default, classes and their members are non-serializable. The NonSerializedAttribute attribute is only needed if a member of a serializable class should not be serialized.
I can think of two reasons:
It could be vital that the field isn't serialised. Hence if in the future the class is made serialisable, this won't introduce a bug, inefficiency or security issue, because without it marking the class serialisable will also do so for the field.
They could be doing some sort of custom use of the attribute
In case 2 it'll be clear from elsewhere in the code that this is what's happening. Number 1 is good practice though.
Case 1 is good practice, it can be worth balancing YAGNI ("You Aren't Gonna Need It" - not doing work "in case it's needed later") with considering "okay, but if I do need it later, it'll be a disaster if someone misses that this field is an exception.
So, while it has no effect here, it is definitely a good practice for scenarios where it begins to have an effect.
Edit: Another possibility is that it is cruft from a previous version where it was indeed serialisable or the author was in two minds at the time and it was never entirely "finished" (is working code ever entirely finished?). Just because something is in code, doesn't mean it was meant to be that way. Still, if it's really important that something not be serialised, I still say it's good practice to mark this for the reason given above.
MSDN SerializeAttribute states that "Apply the SerializableAttribute attribute to a type to indicate that instances of this type can be serialized. " This implies that without it, the class cannot be serialized. I believe I have attempted this and the serialize will throw an exception if it is attempted on a NonSerializable Type.
I agree with Greg, MSDN states it in a similar manner, citing references is a good idea..
"By default, classes and their members are non-serializable. The NonSerializedAttribute attribute is only needed if a member of a serializable class should not be serialized."
http://msdn.microsoft.com/en-us/library/dwys85sk(VS.80).aspx
Related
Consider the case of StructLayout(LayoutKind.Explicit):
using System.Runtime.InteropServices;
[StructLayout(LayoutKind.Explicit)]
public struct UnionThingy
{
[FieldOffset(0x00)]
public short word;
[FieldOffset(0x00)]
public byte hiByte;
[FieldOffset(0x01)]
public byte lowByte;
public bool additionalField; // compile error!
}
Attempting to compile the above code results in the error CS0625
'UnionThingy.additionalField': instance field types marked with StructLayout(LayoutKind.Explicit) must have a FieldOffset attribute.
This seems an incredibly useful feature and I'm very curious how it is implemented.
I've read the MSDN tutorials on custom attributes, googled every related term I could think of, taken a look at the documentation for StructLayout and FieldOffset and even examined the metadata for those two attributes with "Go to definition..." in the VS code editor. I've been unable to find any clues on how the relationship between those two attributes is enforced.
If I want to do something similar:
[OptionalCustomAttribute]
public class DecoratedClass
{
[DetailsRequiredByOptionalCustomAttribute(2)] // compiler error if ommitted
public int SomeProperty {get; set;}
}
How would I go about it?
Edit: The question Force usage of custom attribute, proposed as a duplicate, asks how to force classes that inherit from a base class to include an attribute, not how to enforce members of a decorated class to include a certain attribute. Also, the answer provided is "it can't be done", whereas in this case is clearly has been done by the authors of the .net libraries. The question is simply how.
Some attributes contain information for the compiler. So naturally, there is explicit code in the compiler to interpret it and also error messages if this fails.
In our project, we have unit tests which load all types of our assemblies and check some attributes for consistency.
You can also make you application throw exceptions as early as possible (e.g. when starting up) in such cases. This is a simple solution if your application detects such errors anyway. It is important to throw early, otherwise you miss it until it went live...
I would think that adding that attribute to an interface would be helpful make sure you do not create classes that use the interface and forget to make them serializable.
This could be a very fundamental question, but I wanted to ask the experts.
Interfaces define a contract and do not have any state of their own.
Serialization is about saving and loading state into and out of an object model.
Not much point to serializing something that holds no state.
To answer the practical question of forcing an implementation of an interface to be Serializable - this is why the ISerializable interface exists.
In .NET you can declare an interface that should implement other interfaces:
interface MustBeSerializable : ISerializable {}
See some more information here.
If you want to force classes that implement your custom interface IMyInterface to be serializable you can define it has:
interface IMyInterface : ISerializable
{
// Custom interface definition
}
This more clearly indicates that the implementing class should support serialization. This does not remove the need to mark the class with the [Serializable] attribute.
IIRC, you can also create a FxCop custom rule that checks that classes that inherit from IMyInterface are marked with the respective [Serializable] attribute and this way removing the need to classes implement custom serialization.
There are some good albeit esoteric reasons behind what an interface is and isn't which keeps this from being possible. That said however: I agree with you. There are many things that would be useful if we could incorporate them into interfaces. [Serializable] and statics come to mind.
Although they do not fit into the philosophy of what an interface is, they seem to incorporate this vacant grey area in single-inheritance OOP. There are of course work arounds but they feel very forced compared to the original intent.
Well, there is a reason that new classes are not marked as serializable by default: By adding the Serializable attribute, you acknowledge that you have ensured that serialization in your class works, by choosing proper data types for your instance fields and by adding serialization logic, if necessary.
So, if you "forgot" to add the Serializable attribute to your class, you most probably also forgot to check whether serialization really works on your class. Granted, in many cases it will work "out of the box", so adding the attribute is all that remains, but you are supposed to double-check and explicitly acknowledge that fact (by manually adding the attribute).
There is a lot of code in one of our projects that looks like this:
internal static class Extensions
{
public static string AddFoo(this string s)
{
if (s == null)
{
return "Foo";
}
return $({s}Foo);
}
}
Is there any explicit reason to do this other than "it is easier to make the type public later?"
I suspect it only matters in very strange edge cases (reflection in Silverlight) or not at all.
UPDATE: This question was the subject of my blog in September 2014. Thanks for the great question!
There is considerable debate on this question even within the compiler team itself.
First off, it's wise to understand the rules. A public member of a class or struct is a member that is accessible to anything that can access the containing type. So a public member of an internal class is effectively internal.
So now, given an internal class, should its members that you wish to access in the assembly be marked as public or internal?
My opinion is: mark such members as public.
I use "public" to mean "this member is not an implementation detail". A protected member is an implementation detail; there is something about it that is going to be needed to make a derived class work. An internal member is an implementation detail; something else internal to this assembly needs the member in order to work correctly. A public member says "this member represents the key, documented functionality provided by this object."
Basically, my attitude is: suppose I decided to make this internal class into a public class. In order to do that, I want to change exactly one thing: the accessibility of the class. If turning an internal class into a public class means that I have to also turn an internal member into a public member, then that member was part of the public surface area of the class, and it should have been public in the first place.
Other people disagree. There is a contingent that says that they want to be able to glance at the declaration of a member and immediately know whether it is going to be called only from internal code.
Unfortunately, that doesn't always work out nicely; for example, an internal class that implements an internal interface still has to have the implementing members marked as public, because they are part of the public surface of the class.
If the class is internal, it doesn't matter from an accessibility standpoint whether you mark a method internal or public. However it is still good to use the type you would use if the class were public.
While some have said that this eases transitions from internal to public. It also serves as part of the description of the method. Internal methods typically are considered unsafe for unfettered access, while public methods are considered to be (mostly) free game.
By using internal or public as you would in a public class, you ensure that you are communicating what style of access is expected, while also easing the work required to make the class public in the future.
I suspect that "it is easier to make the type public later?" is it.
The scoping rules mean that the method will only be visible as internal - so it really doesn't matter whether the methods are marked public or internal.
One possibility that comes to mind is that the class was public and was later changed to internal and the developer didn't bother to change all the method accessibility modifiers.
I often mark my methods in internal classes public instead of internal as a) it doesn't really matter and b) I use internal to indicate that the method is internal on purpose (there is some reason why I don't want to expose this method in a public class. Therefore, if I have an internal method I really have to understand the reason why it's internal before changing it to public whereas if I am dealing with a public method in an internal class I really have to think about why the class is internal as opposed to why each method is internal.
In some cases, it may also be that the internal type implements a public interface which would mean that any methods defined on that interface would still need to be declared as public.
It's the same, the public method will be really marked as internal since it's inside a internal class, but it has an advantaje(as you guested), if you want to mark the class as public, you have to change fewer code.
For the same reason as using public methods in any other class - so that they're public to the outside of the containing type.
Type's access modifier has exactly zero to do with its members' access modifiers. The two decisions are made completely independently.
Just because certain combinations of type and members' modifiers produce seemingly (or as others call it "effectively") the same result doesn't mean they're semantically the same.
Local access modifier of a an entity (as declared in code) and its global effective access level (as evaluated through the chain of containment) are completely different things, too. An open office inside of a locked building is still open, even though you can't really enter it from the street.
Don't think of the end effect. Think of what you need locally, first.
Public's Public: classic situation.
Public's Internal: type is public but you want some semi-legal access in the assembly to do some hacky-wacky stuff.
Internal's Public: you hide the whole type but within the assembly it has a classic public surface
Internal's Internal: I can't think of any real world example. Perhaps something soon to become public's internal?
Internal's Public vs Internal's Internal is a false dilemma. The two have completely different meaning and should be used each in their own set of situations, non-overlapping.
internal says the member can only be accessed from within the same assembly. Other classes in that assembly can access the internal public member, but would not be able to access a private or protected member, internal or not.
I actually struggled with this today. Until now I would have said that methods should all be marked with internal if the class was internal and would have considered anything else simply bad coding or laziness, specially in enterprise development; however, I had to sub class a public class and override one of it's methods:
internal class SslStreamEx : System.Net.Security.SslStream
{
public override void Close()
{
try
{
// Send close_notify manually
}
finally
{
base.Close();
}
}
}
The method MUST be public and it got me thinking that there's really no logical point to setting methods as internal unless they really must be, as Eric Lippert said.
Until now I've never really stopped to think about it, I just accepted it, but after reading Eric's post it really got me thinking and after a lot of deliberating it makes a lot of sense.
There does be a difference.
In our project we have made a lot of classes internal, but we do unit test in another assembly and in our assembly info we used InternalsVisibleTo to allow the UnitTest assembly to call the internal classes.
I've noticed if internal class has an internal constructor we are not able to create instance using Activator.CreateInstance in the unit test assembly for some reason. But if we change the constructor to public but class is still internal, it works fine.
But I guess this is a very rare case (Like Eric said in the original post: Reflection).
I think I have an additional opinion on this. At first, I was wondering about how it makes sense to declare something to public in an internal class. Then I have ended up here, reading that it could be good if you later decide to change the class to public. True. So, a pattern formed in my mind: If it does not change the current behavior, then be permissive, and allow things that does not makes sense (and does not hurt) in the current state of code, but later it would, if you change the declaration of the class.
Like this:
public sealed class MyCurrentlySealedClass
{
protected void MyCurretlyPrivateMethod()
{
}
}
According to the "pattern" I have mentioned above, this should be perfectly fine. It follows the same idea. It behaves as a private method, since you can not inherit the class. But if you delete the sealed constraint, it is still valid: the inherited classes can see this method, which is absolutely what I wanted to achieve. But you get a warning: CS0628, or CA1047. Both of them is about do not declare protected members in a sealed class. Moreover, I have found full agreement, about that it is senseless: 'Protected member in sealed class' warning (a singleton class)
So after this warning and the discussion linked, I have decided to make everything internal or less, in an internal class, because it conforms more that kind of thinking, and we don't mix different "patterns".
This cannot be done in C#. Any way to do it?
...
laugh, in case my little pun wasn't understood, what I mean is: how can I mark a property in C# as NonSerialized? Of course, when the property contains logic, it's natural to be unable to do it, but Auto-Properties are serializable, and, as such, I would expect to have some way to allow me to prevent their serialization.
[NonSerialized]
public string MyProperty { get; set; }
Is an error
[XmlIgnore]
public string MyProperty { get; set; }
Is not an error
NonSerialized Indicates that a field of a serializable class should not be serialized.
XmlIgnore Instructs the Serialize method of the XmlSerializer not to serialize the public field or public read/write property value
so, if you ask
I would expect to have some way to allow me to prevent their serialization.
the answer yes, if you're using XmlSerializer
For events, you can use [field:NonSerialized], but for auto-properties this does not work. It seems like it would be a very logical way to handle auto-properties as well, but for some reason it doesn't seem to have been implemented.
Edit * :
Auto Implemented Properties are backed by an anonymous field which you don't really have access to, attributes are designed to be controlled by a reflection based mechanism. These fields cannot be referenced by the reflection mechanism (because they are anonymous). This compiler feature would require a lot of changes to the generation of auto-properties... It would also require that the compiler treat auto-properties as fields for the purpose of marking field attributes onto them.
To answer the more fundamental part of the question - your point was that Auto-Properties are serialized and so there should be a way to control their serialization. You're right - but auto properties are meant as a shorthand and were never designed to give you the full flexibility, but rather to allow you to easily extend their functionality the "long" way if you ever needed it.
I added the more details answer from my comments to the body of the answer.
I theory yes, it's possible. In practical nope, not possible.
Serialization classes only works on private fields. When you define a auto property; at behind the scenes compiler automatically generates a private field for it. That means this is a language feature not a .net framework feature.
Also serialization classes are included in redbits, which is any change prohibited due compatibility except bug fixes.
I hope thats helps.
What was said above is right: You can't prevent an auto-implemented property from being serialized by setting an attribute like [NonSerialized]. It just does not work.
But what does work is the [IgnoreDataMember] attribute in case you are working with an WCF [DataContract]. So
[DataContract]
public class MyClass
{
[DataMember]
public string ID { get; set; }
[IgnoreDataMember]
public string MySecret { get; set; }
}
will get serialized under WCF.
Although since WCF is an opt-in technology, you can also just omit the [IgnoreDataMember] and it will work as well. So maybe my comment is a little academical ;-)
You could probably do this with Mono.Cecil, a bytecode manipulation library. Theoretically, you could add custom attributes to the hidden backing field. This is so inconvenient, however, that I don't think it warrants an example.
If you had a large application with your own postprocessor, you might consider creating your own substitute for NonSerializedAttribute that could be applied to properties. The postprocessor could then use Mono.Cecil or similar to apply NonSerializedAttribute to the backing fields. It's quite common for large applications to undergo such postprocessing to save that extra bit of typing.
[NonSerialized] public decimal yourproperty;
(decimal as example.)
Also remember, if you want enable your class to initialize a nonserialized member automatically, use the IDeserializationCallback interface and then implement IDeserializationCallback.OnDeserialization.
When defining a class as internal, do you define what would usually be public fields as internal? Or do you leave them as public? I have a set of classes with public/private methods that I have decided to set as internal. Now, should I change the class' modifier to internal and let the rest of the methods/properties as they are (public/private) or switch them to (internal/private)?
I don't see a big point in changing it to internal, and if by some reason later I want to set them back to public it's going to give a lot of work to have to put them back to public again.
Any other thoughts on this?
I can't see any reason not to leave them as public, as your class won't be visible to outside assemblies anyway. The only case where I think this might matter is when using reflection over that class.
If I have a class that is internal, I leave the class members as public (or protected/private of course if that's what they were). I find that often I have classes that I hope I can keep internal that I end up having to expose eventually and switching all the appropriate members back to public is annoying.
You defnitely shouldn't change private members to internal as that would make them more accessible. There is no need to change public members to internal since nothing outside of the defining assembly will ever be able to get a reference to an internal class anyway.
I think you should give generally members the same visibility as you would if the Type were itself public.
That is, members that are part of the public API should be public, and members that are special-purpose helpers that should only be visible to "friend" classes should be internal.
This means there will be no changes to member visibility if you ever decide to make the Type public.
More importantly, it also documents your intention - anyone reading your code will be able to identify which (if any) members are intended to be internal.
We use internal keyword for members in internal classes, so that the intention is clear. However it fails if one implicitly implement internal interfaces, where the members have to be defined as public. We dont know why and see this as an accidental mistake in the language specification that we have to live with.
Dig around in Reflector for a bit and you'll see that the BCL itself is wildly inconsistent over this. You'll see many internal classes with public members and many others with internal members. Several classes even mix and match the two with no particular rhyme or reason that I'm able to discern.
There is no "right" answer here, but there are a few things you should consider whenever you need to make a decision on this:
internal members cannot implicitly implement an interface, and explicit implementations are always private. So if you want interface members to be accessible through the class instance (the Dispose method of IDisposable is a common one), they need to be public.
Type visibilities can change. You might decide down the road that an internal class has some valuable functionality that you want to make available to the outside. But if you do, then all public members become accessible by everyone. You should decide in advance if this is what you want.
On the other hand, another reason you might make an internal class public is if you decide that you need to subclass it and that the derived classes should be in a different assembly. In this case, some of your internal members should probably be protected internal instead, otherwise derived classes won't have access to members they might need.
In the end, what it all comes down to is writing code to be read and maintained by other people. The modifier internal can mean two very different things to a maintenance programmer:
That it doesn't seem useful to the outside world, but wouldn't actually be harmful either. A typical example would be a utility class that was whipped up in 5 minutes and doesn't do much validation or error checking. In this case, it's OK for someone to make it public as long as they tighten up the code a little and/or document how to use it properly. Make this assumption explicit by making the members public.
That it's actually not safe for outside consumption; it might manipulate some protected state, leave handles or transactions open, etc. In this case, you really want to make the individual methods internal to make it absolutely clear that nobody else should be using this class, ever.
Choose whichever one is appropriate for your scenario.