The title pretty much says it all. When I’m doing some reflection through my classes, will the MemberInfo.GetCustomAttributes() method preserve the order of attributes on a member, or not? The official documentation does not say anything one way or the other.
In case you’re wondering why I would need this, here’s the full explanation. It’s lengthy and not needed for the question as it is posed now, but perhaps someone can come up with an alternative solution to the greater problem which does not involve relying on attribute enumeration order.
I’m trying to make a flexible framework for an (ASP.NET) application that is expected to have a pretty long lifetime. Over the course it will gain many forms that will have to be accessible from the menu. To make life easier for the developers to come I’ve made a MenuItemAttribute which you can apply to a form’s class. This attribute has an unlimited amount of string parameters in its constructor which allows a developer to specify where exactly will the form reside in the menu. A typical usage example would be something like [MenuItem('Company', 'Clients', 'Orders')] which would then mean that the menu should have an item ‘Company’ under which there would be an item ‘Clients’ under which there would be an item ‘Orders’ – which would then open the form. A single form can have several of these attributes if needed – it will then be acessible from several places in the menu.
Obviously the whole menu is built in runtime by enumerating through all the classes in my assemblies and searching for this attribute. However recently I’ve gotten a request that the menu items should be sorted in a predefined way. Forms that have related functionality should be next to each other in the menu. Note that this is NOT alphabetical sorting, but a predefined order that the developers specify.
This then brings the problem – how do I specify the order in these attributes? Since one MenuItemAttribute describes a whole hierarchy, the order specification should also include order numbers for the whole (or at least a part) of the hierarchy. An order number for just the lower level of the hierarchy is not sufficient.
I could make another attribute – MenuItemOrderHintAttribute, but that would then bring problems with cases when there is more than one MenuItemAttribute. Hence the original question.
I could also extend the MenuItemAttribute to take either two arrays or an array of pairs, but that then would complicate the syntax a lot. The last idea is that I could make the strings have special format, but that would be rather messy IMHO.
OK, I’ve got another idea. Let’s use the ordering that Jon Skeet suggested. This will allow to specify the order for the last level of the hierarchy, not the higher ones. But I could modify the attribute so that it applies not only to classes, but also to the assembly itself. In this case the menu item would not have an associated form. At the assembly level these attributes could then be used to specify the ordering among higher levels of the hierarchy.
This is then a tradeoff between a centralized and decentralized menu system. Any thoughts why this would be a bad idea?
I’d put a single extra (optional) value in the MenuItemAttribute constructor, which is ‘order’ or ‘priority’:
I’m not saying it would be pretty, but it would effectively allow you to specify the ordering.