posted on Tuesday, June 28, 2005 9:52 PM
by
johnwood
Reflection changes in .Net 2.0 - Order of members
Something I think anyone making extensive use of reflection in .Net should know…
I use reflection for all kinds of things in my applications. In one instance, I keep a cache of all the PropertyInfo and FieldInfo members of my classes so that I can set the properties by numeric index later on. However I have since found that this feature breaks when I run the same code in .Net 2.0.
It turns out that it's to do with the *order* that fields and properties are returned in .Net. In previous versions you could pretty much rely on the order of members returning from calls such as GetFields: it would match the order the members are defined in the source code.
In .Net 2.0 however. If you rely on the order of members being returned in your code, that code will break in .Net 2.0 and there's nothing you can do to get Microsoft to fix it. Not only is the order of returned members different, it can change while the application is running!
I got a nice, lengthy, detailed explanation from a guy called Jesse Kaplan at Microsoft. I've pasted it below so you can better understand why this change was made:
Your application seems to be hitting a change we made in how items are returned back from reflection. In previous versions of the .Net FX we always chose the same pattern to return items from reflection, unfortunately the problem is that between versions of the FX the pattern remained the same but the order things were returned still changed. For example, if an overload was added to a parent type, what used to be the 6th method in the type was no longer the 6th method and applications would fail.
This type of problem fell into a general bucket we call "deterministic non-determinism." It basically means that for a given platform/os/application layout/FX version the behavior would be deterministic, but that the behavior was not something that could preserved between releases. This type of issue makes it very hard to get predictable behavior out of your application. What we’ve done in 2.0 is to find cases of this type of behavior and if possible make it completely deterministic to remove and ambiguities or, if completely deterministic behavior was not possible, we would opt for making the behavior non-deterministic enough that it would be hard to write a new application that relied on this behavior.
When it came to the order items were being returned from reflection we couldn’t provide a model where a given field would always be in a specific position in the list, so we moved to a model where the return order was somewhat randomized over the course of the application and thus make it more difficult to take dependencies on this.
In the past we haven’t don’t such a good job documenting best practices for avoiding these types of issues, but by the time we release the final version of the NetFX 2.0 we will have more documentation that will help you avoid these types of problems in the future.
I'm not 100% sure I accept his explanation. Relying on the position of members between sessions is clearly something that shouldn't be deterministic or constant, but I can't see what's wrong with relying on the order of the members during the session. This used to work in 1.1 and doesn't in 2.0, it seems, simply because Microsoft don't think people should be relying on the position of members remaining constant between sessions. The solution implemented doesn't just make it difficult to unknowingly rely on the position of the members, it makes it impossible to determine the order of the members -- something which *is* constant and deterministic while the application is running.
Alas I guess it's too late to make any changes...
Please visit my blog at DevAuthority to leave comments!