What "Attributes" really are? - c#

I've already read a lot about attributes and I know rather much about them.
But one thing that I can't understand is : "What they really are?".
I mean if this isn't inheritance or interface implementation or other OOP understandable concepts so what concept is this?
what happens behind the scene when you use and attribute for a class or a class member?
I have read other related posts in this site. But they don't give much information about what really happens. They are more about usage of attributes. And an incomprehensibility explanation of what they really are.In the other post this is what declares them : "Metadata. Data about your objects/methods/properties." which doesn't clarify concepts

They are simply metadata stored in the underlying definition (not instance) of the type. For example, if I do:
[Description("some text")]
public string Name {get;set;}
then the fact that DescriptionAttribute with a description constructor-parameter of "some text" is stored in the IL against the property Name. This has no impact on the cost of each instance, and it does nothing by itself. The only time this data is used is if code explicitly asks the runtime something like:
"what additional attribute metadata do you have against Name ?"
"does Name have a DescriptionAttribute ?"
"please construct me the DescriptionAttribute stored against Name, if one"
and then does something with the result.
CAVEAT: there are some attributes that are processed differently by the compiler and/or CLI, and are implemented differently. [Serializable], for example, becomes an IL type flag - not an IL attribute - but the runtime shims it so that the APIs report it as though it were the other.

Attributes are a very simple concept, but they are complicated by the fact that so many parts of the framework use them in ways that seem like magic.
Attributes are nothing more than Metadata. That is, they are essentially comments that the framework can read at runtime that describe things about the type. There are all kinds of attributes that are for various purposes, and there is various code written that looks for these attributes.
Attributes by themselves don't do anything. They need some other code to read them, and then do something based on what they find.
Attribute classes can be instantiated, and then code in them can be executed, but again, only if some other code requests it. Much of this code is often hidden by frameworks. For instance, in MVC there are attributes used for declaring methods to be Post or Get methods... or that a method must be authenticated before it can be called... These attributes are only useful because the MVC framework has code to check for them, and take action based on them.
In short, an attribute does nothing by itself. It only functions in conjunction with other code (usually in the framework) that makes use of it. As such, attributes can be almost anything that anyone can dream up.

Related

How to parse source code fragment to System.Type

I have a set of strings like this:
System.Int32
string
bool[]
List<MyType.MyNestedType>
Dictionary<MyType.MyEnum, List<object>>
I would like to test if those strings are actually source code representations of valid types.
I'm in an environment, that doesn't support Roslyn and incorporating any sort of parser would be difficult. This is why I've tried using System.Type.GetType(string) to figure this out.
However, I'm going down a dirty road, because there are so many edge cases, where I need to modify the input string to represent an AssemblyQualifiedString. E.g. nested type "MyType.MyNestedType" needs to be "MyType+MyNestedType" and generics also have to be figured out the hard way.
Is there any helper method which does this kind of checking in .Net 2.0? I'm working in the Unity game engine, and we don't have any means to switch our system to a more sophisticated environment with available parsers.
Clarification
My company has developed a code generation system in Unity, which is not easily changed at this point. The one thing I need to add to it, is the ability to get a list of fields defined in a class (via reflection) and then separate them based on whether they are part of the default runtime assembly or if they are enclosed within #if UNITY_EDITOR preprocessor directives. When those are set, I basically want to handle those fields differently, but reflection alone can't tell me. Therefore I have decided to open my script files, look through the text for such define regions and then check if a field is declared within in them, and if true, put it in a separate FieldInfo[] array.
The one thing fixed and not changeable: All script will be inspected via reflection and a collection of FieldInfo is used to generate new source code elsewhere. I just need to separate that collection into individual ones for runtime vs editor assembly.
Custom types and nested generics are probably the hard part.
Can't you just have a "equivalency map to fully qualified name" or a few translation rules for all custom types ?
I guess you know by advance what you will encounter.
Or maybe run it on opposite way : at startup, scan your assembly(s) and for each class contained inside, generates the equivalent name "as it's supposed to appear" in your input file from the fully qualified name in GetType() format ?
For custom types of other assemblies, please note that you have to do things such as calling Assembly.LoadFile() or pass assembly name in second parameter to GetType() before to be able to load them.
See here for example : Resolve Type from Class Name in a Different Assembly
Maybe this answer could also help : How to parse C# generic type names?
Could you please detail what is the final purpose of project ? The problem is a bit surprising, especially for a unity project. Is it because you used some kind of weird serialization to persist state of some of your objects ?
This answer is more a few recommandations and questions to help you to clarify the needs than a definitive answer, but it can't hold in a single comment, and I think it provide useful informations

PInvoke Implementation on Fields

So today I was browsing around ILSpy to get a better understanding of how .NET performs DllImports on external methods, when I came across something odd:
When searching for references to the enum value PInvokeImpl, which is defined in the System.Reflection.MethodAttributes enumeration, I noticed a matching definition in System.Reflection.FieldAttributes.
Well sure enough, this appears to be more than just a behind-the-scenes, re-use of enumeration values: System.Reflection.FieldInfo has an publicly defined property called IsPinvokeImpl, which specifically checks if this implementation flag is set.
Interestingly enough, the MethodInfo class doesn't even have this property - it must be determined from the MethodImplementationFlags property instead.
Question:
Is it actually possible for a field to be PInvoke implemented, or is this just a stub implementation in the .NET framework for balance between field decorations and method decorations?
If it is possible, can it be done in C#, or is this a feature that requires C++/CLI?
When you look at the MSDN description for FieldAttributes then you'll see it documented as "Reserved for future use". That future has not arrived yet so its intention is not nailed down.
Types like FieldAttributes are not arbitrary, they follow the CLI specification. Ecma-335 nails down what the metadata in a .NET assembly needs to look like and how it should be interpreted. This document does reveal an interesting quirk.
Chapter II.16.1 describes the field attributes, you'll see a close match between the metadata tokens and the FieldAttributes enum. Note however that pinvokeimpl is missing in that chapter.
Chapter II.23.1.5 gives the specific values of the attributes, it has PInvokeImpl with the value 0x2000. Description is "Implementation is forwarded through PInvoke". Compare to II.23.1.10, describes method attributes. It has many values in common with field attributes.
This looks a lot like a copy/paste bug :)
Digging a bit deeper through the .NET Framework source code, the CLR and jitter only ever considers pinvokeimpl on methods. The C# compiler however appears to be based on the CLI spec and actually sets the attribute. Appears in emit.cpp, RegMeta::_DefinePinvokeMap() function, it will set the attribute if this function is called for a field instead of a method. That never actually happens.
From FieldAttributes:
PinvokeImpl Reserved for future use.
So I would say:
Q: Is it actually possible for a field to be PInvoke implemented
A: No

Ndoc on properties best practice?

My project manager last week hinted at using ndoc on properties within a class. Is this something that should be done? Is it considered best practice to do this or not? I am currently expanding all my ndoc for the section of a project that I am working on but do not know how deep I need to go with it. I have of course provided summaries, params, returns and remarks to the class and each method but do properties require ndoc too?
Public properties are a contract to the outside world I think they should be documented.
Internal properties will only be used in the same assembly so you could get away with not documenting them.
Protected properties will only be used in derived classes (internal or public) so they might be in need of some documentation.
Private properties will only be used in the class itself so, again, you could get away with it.
Note that "getting away with not documenting it" suggests the way I feel about this: you should document. At the same time I realize that sometimes you need to do one thing or the other...
Perhaps you should ask this on http://programmers.stackexchange.com
Just like any other members, the meaning of properties should be documented. This should include not only what the property does or what it can be used for, but also its initial value, special cases (e.g. values that must not be assigned; values that would cause an exception or automatically be replaced with other values), as well as possibly the ramifications and purpose of overriding the property in a derived class where this is possible.
Public properties should definitely always be documented, whether your chosen documentation workflow uses GhostDoc, NDoc, or whatever. XML comments on public properties and methods show up in Intellisence when people use it, so there's no reason to not add something there. Even if the name of the property explains what it does, it's very nice to have XML comments there to confirm that. There are plenty of gotchas in plenty of code, so it's courteous to let the people who use your code know they're not walking into one.
Private properties can go either way. I'd hesitate to call it a particular best practice since to see the comments you have to be in the class, at which point you can just look at its usage trivially. That said, I still put XML comments on private properties, if for nobody else then for myself. There's no way you will remember what you were doing 6 months from now and any structural comments you can add will make it easier to pick up where you left off.

Is it good practice to use reflection in your business logic?

I need to work on an application that consists of two major parts:
The business logic part with specific business classes (e.g. Book, Library, Author, ...)
A generic part that can show Books, Libraries, ... in data grids, map them to a database, ...).
The generic part uses reflection to get the data out of the business classes without the need to write specific data-grid or database logic in the business classes. This works fine and allows us to add new business classes (e.g. LibraryMember) without the need to adjust the data grid and database logic.
However, over the years, code was added to the business classes that also makes use of reflection to get things done in the business classes. E.g. if the Author of a Book is changed, observers are called to tell the Author itself that it should add this book to its collection of books written by him (Author.Books). In these observers, not only the instances are passed, but also information that is directly derived from the reflection (the FieldInfo is added to the observer call so that the caller knows that the field "Author" of the book is changed).
I can clearly see advantages in using reflection in these generic modules (like the data grid or database interface), but it seems to me that using reflection in the business classes is a bad idea. After all, shouldn't the application work without relying on reflection as much as possible? Or is the use of reflection the 'normal way of working' in the 21st century?
Is it good practice to use reflection in your business logic?
EDIT: Some clarification on the remark of Kirk:
Imagine that Author implements an observer on Book.
Book calls all its observers whenever some field of Book changes (like Title, Year, #Pages, Author, ...). The 'FieldInfo' of the changed field is passed in the observer.
The Author-observer then uses this FieldInfo to decide whether it is interested in this change. In this case, if FieldInfo is for the field Author of Book, the Author-Observer will update its own vector of Books.
The main danger with Reflection is that the flexibility can escalate into disorganized, unmaintainable code, particularly if more junior devs are used to make changes, who may not fully understand the Reflection code or are so enamored of it that they use it to solve every problem, even when simpler tools would suffice.
My observation has been that over-generalization leads to over-complication. It gets worse when the actual boundary cases turn out to not be accommodated by the generalized design, requiring hacks to fit in the new features on schedule, transmuting flexibility into complexity.
I avoid using reflection. Yes, it makes your program more flexible. But this flexibility comes at a high price: There is no compile-time checking of field names or types or whatever information you're collecting through reflection.
Like many things, it depends on what you're doing. If the nature of your logic is that you NEVER compare the field names (or whatever) found to a constant value, then using reflection is probably a good thing. But if you use reflection to find field names, and then loop through them searching for the fields named "Author" and "Title", you've just created a more-complex simulation of an object with two named fields. And what if you search for "Author" when the field is actually called "AuthorName", or you intend to search for "Author" and accidentally type "Auhtor"? Now you have errors that won't show up until runtime instead of being flagged at compile time.
With hard-coded field names, your IDE can tell you every place that a certain field is used. With reflection ... not so easy to tell. Maybe you can do a text search on the name, but if field names are passed around as variables, it can get very difficult.
I'm working on a system now where the original authors loved reflection and similar techniques. There are all sorts of places where they need to create an instance of a class and instead of just saying "new" and the class, they create a token that they look up in a table to get the class name. What does this gain? Yes, we could change the table to map that token to a different name. And this gains us ... what? When was the last time that you said, "Oh, every place that my program creates an instance of Customer, I want to change to create an instance of NewKindOfCustomer." If you have changes to a class, you change the class, not create a new class but keep the old one around for nostalgia.
To take a similar issue, I make a regular practice of building data entry screens on the fly by asking the database for a list of field names, types, and sizes, and then laying it out from there. This gives me the advantage of using the same program for all the simpler data entry screens -- just pass in the table name as a parameter -- and if a field is added or deleted, zero code change is required. But this only works as long as I don't care what the fields are. Once I start having validations or side effects specific to this screen, the system is more trouble than it's worth, and I'm better off to fall back to more explicit coding.
Based on your edit, it sounds like you are using reflection purely as a mechanism for identifying fields. This is as opposed to dynamic behavior such as looking up the fields, which should be avoided when possible (since such lookups usually use strings which ruin static type safety). Using FieldInfo to provide an identifier for a field is fairly harmless, though it does expose some internals (the info class) in a way that is not entirely ideal.
I tend not to use reflection where i can help it. by using interfaces and coding against these i can do a lot of things that some would use reflection for.
But im a big fan of if it works, it works.
Also by using reflection you probably have something that can adapt fairly easily.
Ie the only objection most would have is fairly religious ... and if your performance is fine and the code is maintainable and clear .... who cares?
Edit: based on your edit i would indeed use interfaces to achieve what you want. Unless i misunderstand you.
I think it is a good idea to stay away from Reflection when possible, but dont be afraid to resort to it when it provides a better or more flexible solution to your problem. The performance hit for anything but tight loop operations is likely to be minimal in the overall scheme of an application or Web Form request.
Just a good article to share about reflection -
http://www.simple-talk.com/dotnet/.net-framework/a-defense-of-reflection-in-.net/
I tend to use interfaces in my business layer and leave the reflection to my presentation layer. This is not an absolute but rather a guideline.

When to use attributes instead of properties?

Are there specific cases when one should use custom attributes on class instead of properties?
I know that properties are preferrable because of their discoverability and performance, but attributes... When should I definitely use them?
UPDATE:
Here is a post by Eric Lippert about this decision.
Eric Lippert has a great blog post tackling exactly this decision.
His summary is:
In short: use attributes to describe your mechanisms, use properties to model the domain.
I'd also add to that the consideration that an attribute value is effectively static - in other words it's part of the description of the type rather than any instance of the type.
One tricky bit can come when every instance of some base type has to have a property (e.g. a description) but different concrete derived types want to specify descriptions on a per-type basis rather than per-instance. You often end up with virtual properties which always return constants - this isn't terribly satisfactory. I suspect Delphi's class references might help here... not sure.
EDIT: To give an example of a mechanism, if you decorate a type to say which table it's from in the database, that's describing the data transfer mechanism rather than saying anything about the model of data that's being transferred.
There are two use cases:
1) Using a custom attribute that someone else has defined, such as the System.LoaderOptimization attribute that may be used on the Main method. These kinds of attributes are used to direct platform code such as the CLR, WPF, WCF or the debugger to run the code in a certain way, and can be very useful at times. Reading books on various platform topic is a good way to learn when and how to use these attributes.
2) Creating your own custom attribute and using it to decorate a class (or method, property, etc). These have no effect unless you also have code that uses Reflection to notice those attribute usages and change the behavior in some way. This usages should be avoided whenever possible because of very poor performance, orders of magnitude larger than, say, accessing a static member of a class.

Categories